-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Property named '$type' is silently not migrated via Cosmos DB migration #97
Comments
I encountered a similar issue but it in my case it was with the |
I had the same problem happening. This could have been really dangerous for us. Is it something we missed in the migrationsettings? |
Had the very same problem with the property named $type and it took us hours to understand what was happening because the lack of the field. VERY VERY DANGEROUS BEHAVIOR! |
Same problem. This tool would be great if this CRITICAL issue would be resolved. |
Yes, it silently ignore and without warnings |
The problem: Troubleshooting: Initial Solution Thoughts: @jbowen-solliance What are your thoughts? |
Can anyone seeing this issue provide a reproduction scenario: source and sink used, settings, a sample of data used? In running some basic tests of JSON->Cosmos-NoSQL and Cosmos-NoSQL->JSON I didn't see the $type property being dropped so there's something specific about these scenarios that I'm missing. I tested with this data as "json-in_typed.json": [
{
"$type": "System.Object",
"RealEstateType": "apartmentRent",
"Title": "Test221",
"MatterportUrl": ""
}
] migrationsettings.json for import to Cosmos, including two different options for WriteMode that have different internal serialization behavior: {
"Source": "json",
"Sink": "cosmos-nosql",
"SourceSettings": {
"FilePath": "json-in_typed.json"
},
"SinkSettings": {
"ConnectionString": "FILL IN",
"Database": "database",
"Container": "typed",
"PartitionKeyPath": "/id",
"RecreateContainer": true,
"WriteMode": "InsertStream"
//"WriteMode": "Insert"
}
} migrationsettings.json for export from Cosmos: {
"Source": "cosmos-nosql",
"Sink": "json",
"SourceSettings": {
"ConnectionString": "FILL IN",
//"IncludeMetadataFields": true,
"Database": "database",
"Container": "typed"
},
"SinkSettings": {
"FilePath": "json-out_typed.json",
"Indented": true
}
} @JefSchraag: I assume your problem with "_" was on export from Cosmos, which excludes metadata properties (those with leading underscores) by default. The IncludeMetadataFields setting above changes that behavior. |
For our issue, it happens when the $type was a sub-property { We have the IncludeMetadataFields property set to true on the Source and Sink settings. Our migrations picked up the _ properties of CosmosDb (e.g. _ts) at the top level once we started including the meta data flag. Our use cases for the tool will be Cosmos-to-Cosmos, Cosmos-to-JSON and JSON-to-Cosmos transfers. Let me know if there is anything else relevant to include to help with the investigation. |
@JohnDStrasz can you confirm whether #122 fixes this for you? I included the sample you provided in my testing and confirmed the change during export but it would be good to make sure there's not something else you're seeing. |
I pulled down your feature branch with the change, compiled, brought over my "known working" migrationsettings.json. However, I get the following stack trace when running with dmt.exe in your feature branch under the Core project. Using Cosmos-nosql Source |
I found some more time to test and I debugged into the code. All Cosmos transfers fail, regardless of whether they have the $type property or not, in the UpsertItemAsync line of the PopulateItem method in the CosmosDataSinkExtension.cs file
I am compiling in Debug mode. |
@JohnDStrasz Another recent change caused a conflict in the serializer settings which is now fixed so this should be back to working for round trip transfers to and from Cosmos. |
It works!!! I compared a doc between the source and destination and it was exact, except for the usual Cosmos internal fields. This is huge for us John. Thank you so much. Looking forward to it being merged to master soon. |
…through Fixes #97 for outputting JSON metadata properties on child objects
Fixes are now included in Release 2.1.5. Thank you @JohnDStrasz for help reproducing and validating! |
Anytime! |
Hey,
First of all, thank you for this amazing tool. I was successfully able to migrate data directly from and to Cosmos DB.
Though, for some reason, the property named
$type
was not copied with the rest of the data and was silently omitted. This value is used by the .NET's JSON library Newtonsoft.Json for complex data type handling. The omitted field led to changed data deserialization behavior, which in turn led to issues for my applications.To clarify, this:
was changed to this:
My guess would be that either this is the case for all fields with an
$
in it, or, since the tool itself seems to use Newtonsoft.Json, this usage inadvertently stops propagating that field. I would assume this is unintentional behavior, i.e. a bug. Though if it's indeed intended behavior, then I would suggest outputting a warning of some kind if this is detected as well as adding a note to the documentation.For my testing, I used version 2.1.4 on Mac OS X Ventura 13.0.
The text was updated successfully, but these errors were encountered: