[CSHARP-1612] Moving code from 1.x to 2.x Created: 23/Mar/16  Updated: 05/Apr/19  Resolved: 16/May/16

Status: Closed
Project: C# Driver
Component/s: BSON, GridFS
Affects Version/s: 1.10.1, 2.2.3
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Peter Bielek Assignee: Unassigned
Resolution: Done Votes: 0
Labels: question
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Windows Server 2012


Attachments: File DbRepository.cs    

 Description   

I'm trying to port my code from the C# 1.x driver to the 2.x

I was able to translate the queries to 2.x where I had trouble is with GridFS Upload and Delete was giving me trouble because I used GUIDs for IDs and 2.x wanted ObjectID.

I attached my code file, the methods that gave me issues were SaveAttachment and DeleteEmail

Delete email because I'm trying to delete the JSON doc and the associated GridFS file

For now I'm using the 2.x MongoDB.Driver.Legacy and keeping my code as is but I would like to rewrite this code to 2.x format. I do need this code to run against a current 2.4 database and schema and I'm trying to future proof it to be 3.2 compatible when the MongoDB instances get upgraded to 3.2.



 Comments   
Comment by Robert Stam [ 23/Mar/16 ]

The goal is for the Legacy API to be dropped eventually.

We have not yet determined a date for that to happen.

Comment by Peter Bielek [ 23/Mar/16 ]

When would you expect the "Legacy" mode of the 2.x driver to fall off? Is there a end of life for that feature?

Comment by Robert Stam [ 23/Mar/16 ]

Schema migrations are always awkward. Your options are:

1. Run an offline script/program to modify all existing data to conform to the new schema
2. Write your program to accept a mix of the old and new schema data (new data is written in the new schema, existing data remains in the old schema)

The second option has the advantage of not requiring any downtime, at the cost of slightly more complicated code.

In this case if you simply copy the _id of all existing GridFS documents to a new

{ metadata.attachment_id } field and also put the GUID of all new GridFS files in the same { metadata.attachment_id }

field your schema migration is pretty minimal.

You can leave the _id's of all existing GridFS files alone, while new GridFS files will have an _id that is an ObjectId and have your attachment_id in the metadata field. It wouldn't really matter that existing files have an _id that is not an ObjectId (though you'll have to use a deprecated overload of DownloadXyz to read them).

Comment by Peter Bielek [ 23/Mar/16 ]

Unfortunately both options require me to update the current data in the 2.4 instance to support the new code. I was hoping to not have to reformat the data.
Or am I missing something?

Comment by Robert Stam [ 23/Mar/16 ]

The 2.x implementation of GridFS follows the new GridFS spec, which is intended to provide identical GridFS support across all drivers.

The new GridFS spec does not allow an application to set the id of the uploaded file.

Some options for you are:

1. convert the GUID to a string and use it as the filename
2. add the GUID to the Metadata in the GridFSUploadOptions

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