[CSHARP-1488] Properly implement Flush/FlushAsync for GridFS streams Created: 30/Nov/15  Updated: 22/Oct/22  Resolved: 02/Dec/15

Status: Closed
Project: C# Driver
Component/s: GridFS
Affects Version/s: 2.1.1
Fix Version/s: 2.2

Type: Task Priority: Minor - P4
Reporter: Robert Stam Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to CSHARP-4377 GridFSDownloadStream.Flush must not t... Closed
Backwards Compatibility: Minor Change

 Description   

The abstract Stream class defines Flush and FlushAsync methods that must be implemented by subclasses of Stream.

The normal semantics of Flush and FlushAsync are that any pending data is written to the underlying store immediately. The usual intent when calling Flush is to prevent any data loss in the event the process is aborted.

Clearly we should throw a NotSupportedException when Flush is called on a GridFS download stream (because download streams are read-only and Flush is a method for writable streams). But what should we do when Flush is called on a GridFS upload stream?

In the case of GridFS we can't actually write pending data to the underlying data store (i.e. the GridFS bucket) because GridFS data is written in chunks and we don't have the data for the rest of the chunk yet. Furthermore, a GridFS file isn't actually considered to exist until it is 100% uploaded and the files collection metadata document is written, so even if we decided to flush a partial chunk to the chunks collection (and overwrite it later when the rest of the data for the chunk becomes available), it sill wouldn't serve the purpose of preventing data loss.

The two options for implementing Flush on an upload stream are:

1. Throw a NotSupportedException (because Flush is not supported)
2. Implement Flush as a no-op

The first is arguably more correct, but runs the risk of breaking any code (some of which might be out of the user's control) that calls Flush assuming that it is supported.

The second is more compatible with existing code because it simply does nothing instead of throwing an exception, at the expense of providing the false illusion that the Flush was actually done.

Our current thinking is that compatibility with existing code that might call Flush is more important than accurately reporting that Flush isn't actually supported.

So Flush and FlushAsync for GridFS upload streams will be implemented as no-ops (a download stream will still throw a NotSupportedException).



 Comments   
Comment by Githook User [ 02/Dec/15 ]

Author:

{u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}

Message: CSHARP-1488: Properly implement Flush and FlushAsync for GridFS streams.
Branch: v2.1.x
https://github.com/mongodb/mongo-csharp-driver/commit/78a2272f2ba51216726f3449a1018229d611f59d

Comment by Githook User [ 02/Dec/15 ]

Author:

{u'username': u'rstam', u'name': u'rstam', u'email': u'robert@robertstam.org'}

Message: CSHARP-1488: Properly implement Flush and FlushAsync for GridFS streams.
Branch: master
https://github.com/mongodb/mongo-csharp-driver/commit/f5c299d7630c3211cc3d8869ea6f95fe2c0aa20f

Generated at Wed Feb 07 21:39:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.