[CSHARP-266] Remove support for updating an existing GridFS file Created: 08/Jul/11 Updated: 10/Jun/19 Resolved: 10/Jun/19 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | GridFS |
| Affects Version/s: | 1.1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Robert Stam | Assignee: | Robert Stam |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
No other driver supports updating an existing GridFS file. The reason given is that this is a very dangerous operation, because while the update is in progress the GridFS file is in an intermediate state and if any other process or thread tries to read the GridFS file during that time the results will be unpredictable. This involves removing or changing the following methods: MongoGridFS class: MongoGridFSFileInfo class: This change is scheduled for version 1.3 to provide sufficient time for comments. |
| Comments |
| Comment by Robert Stam [ 03/Apr/14 ] |
|
This feature is only dangerous if multiple processes/threads attempt to use the same GridFS file simultaneously (either multiple updaters, or other readers while the update is in progress). To use this feature safely requires application level locking to ensure that this doesn't happen. An additional danger is that if the client crashes or loses network connectivity before it is done updating the GridFS file (and closing the stream) the GridFS file is left in an inconsistent state. I don't know what the final decision on removing this feature will be... we've delayed action on this for such a long time because the right course of action does not seem immediately obvious. |
| Comment by Jonathan Gaillard [ 02/Apr/14 ] |
|
The in place updates have given us tremendous performance boost over insertion + deletion and I would much prefer the feature to stay in some safe form. |
| Comment by Robert Stam [ 09/Jul/11 ] |
|
Thanks for your feedback. We definitely need to know if people would be affected by removing this feature. Your suggestion that perhaps we could provide a safe way to use this feature instead of just removing it is very helpful. Looking forward to more comments from other users. Thanks again. |
| Comment by emmanuel buah [ 09/Jul/11 ] |
|
Rather than removing the feature, isn't it possible to provide a blocking feature when a file is in read state. Appending to a file is a needed operation, especially saving chucked files where we need to append the chuncks for the files. I know other drivers don't support it but a blocking feature might be a better solution. Obviously, you guys have a better understanding of its risks. Thanks for all your hard work. |
| Comment by Robert Stam [ 08/Jul/11 ] |
|
This change is backward breaking if you were using this capability. |