-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: API
In SERVER-12315 I proposed an improvement of the remove api on GridFS.
In fact others key features are missing from the GridFS & GridFile classes.
The general idea is to be able to easily do CRUD operations:
- Create: current storeFile() methods only allow to set fileName and contentType on the GridFile. According to GridFS Reference there are aliases and metadata too. Also, _fileName_should be optional, and it's not (we can set an empty filename with the buffer api, which is close to "optional", but not exactly the same; but we cannot even do that with tile file api).
- Read: we need a full featured query api for "find": currently we have findFile() & list().
- findFile() should be able to return a list of GridFiles. In fact it would be really useful to have a full-featured queyring api like db.collection.find(): query, skip, limit, sort; or maybe just accept a DBClientCursor to avoid duplicating the find() api.
- list() is probably less useful if findFile() can return multiple GridFiles. If we keep it we could add a full-featured api like proposed findFile().
- Update: GridFile is currently a read-only view of the db; we could add a method to update the fs.files fields (filename, contentType, aliases, metadata). I'm not sure about modifying the data itself. It would require more work anyway.
- Delete: see
SERVER-12315: we need a full featured query api for "remove", like the find api: query, skip, limit, sort; or maybe just accept a DBClientCursor.
A real use-case: multiple files with the same filename, I just want to get a GridFile of the last inserted file given a filename: I cannot use GridFS and GridFile to do that with the current API.