[CSHARP-2646] DateTimeOffsetSerializer should be forgiving of the actual numeric types it encounters during deserialization Created: 22/Jun/19  Updated: 04/Oct/22  Resolved: 04/Oct/22

Status: Closed
Project: C# Driver
Component/s: BSON, Serialization
Affects Version/s: 2.8.0
Fix Version/s: 2.18.0

Type: Improvement Priority: Major - P3
Reporter: Hassan Faghihi Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: neweng, size-xsmall
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Quick Wins
Quarter: FY23Q3
Backwards Compatibility: Fully Compatible

 Description   

I already report this in Shell Section, but as it only affects the `DateTimeOffset` i though i need to tell it in driver section too.

 

I have data imported using Mongo C# Driver, and at some point i noticed my link are generating certification error since they are not using SSL, so i had to update them somehow, i decide to add both version of links, so i had to update my data in place somehow, and the only way i could find was not update method, but looping through, modification, and save...

In this process i didn't modified any data, or convert them to JSON, i just modified the required field, then when i start the project, i faced internal error for those updated users...

The Int32 field somehow turned to Double, yet the Int64 was intact... i modified object created by DateTimeOffset, it creates an array with two item, an Int64, and an Int32....

But the data type got messed with.

db.humanResource.user.find({
	ProfilePictures: {
		$exists: true
	},
	ProfilePictures: {
		$ne: null
	}
}).forEach(function (e, i) {
	for(var i=0; i< e.ProfilePictures.length; i++){
		 e.ProfilePictures[i].CloudinarySecureUrl = updateHttpToHttps(e.ProfilePictures[i].CloudinaryUrl);
	}
	db.humanResource.user.save(e);
})



 Comments   
Comment by Githook User [ 04/Oct/22 ]

Author:

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

Message: CSHARP-2646: DateTimeOffsetSerializer should be forgiving of the actual numeric types it encounters during deserialization.
Branch: master
https://github.com/mongodb/mongo-csharp-driver/commit/3ba59f225716977f6b0a143410405cc6a15935f4

Comment by Hassan Faghihi [ 24/Jun/19 ]

That's good as long as it work...
that's why i post it twice both for shell writer and driver writer, because i think both should check it, like javascript bugs mentioned in book "you don't know JS", fixing it will break existing codes, and it's existance is a bug.

so the driver should work with all builds, and the shell should provide more data consistency.

Comment by Hassan Faghihi [ 24/Jun/19 ]

so i should use $and?

but i'm sure at the time of mongo 3.x the video teacher from mongo university told us to use both $exists and $not null check as they have different meaning...

Comment by Robert Stam [ 24/Jun/19 ]

When doing updates via a shell script it is possible that numeric values could change type. This is because in Javascript all numbers are floats.

I've modified the description of this ticket so that the task becomes to make the `DateTimeOffsetSerializer` more forgiving of the actual numeric types it encounters during deserialization.

Comment by Robert Stam [ 24/Jun/19 ]

Your query has a subtle problem. You can't use the same element name twice in the same document. When you do that in the shell, the second element silently overwrites the first.

So

db.humanResource.user.find({ ProfilePictures : { $exists; true }, ProfilePictures : { $ne : null } })

is actually equivalent to:

db.humanResource.user.find({ ProfilePictures : { $ne : null } })

That might not actually change which documents are matched (since in order for them to not be null they must also exist), but it's important to be aware of this and avoid queries with duplicate element names in the filter document.

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