Reputation: 324
This has got me going in self-recursive circles for two days now.
I have a recursive ObjectModel in which i convert single Objects to Microsoft.Azure.Documents.Document
. As I use recursion, the "phone_numbers" property in the example below is a List(Of Document)
.
How can I get rid of the "_rid", "_self", "_ts", "_etag"
properties? For the lack of knowing what they are called, let me call them meta-properties.
I want to either remove them before saving to the database or - even better - avoid having them generated?
What my code generates:
{
"id": "object768f02af46b24a5c86c1e5eeaae721c6",
"family_name": "Green",
"given_name": "Thomas",
"phone_numbers": [
{
"id": "eb8e6d6b6317499c96c568a2b6088101",
"_rid": null,
"_self": null,
"_ts": 0,
"_etag": null,
"name": "private phone",
"number": "564894654"
},
{
"id": "e8ffb8de9d55489cb84d3342189240c1",
"_rid": null,
"_self": null,
"_ts": 0,
"_etag": null,
"name": "work phone",
"number": "654649684684"
}
]
}
This is the unmodified output of Document.ToString()
before writing it to DocumentDB. I have no idea why there are no meta-tags in the root document at this point. But I don't seem to need them there either, because...
what is saved to the database:
{
"id": "object768f02af46b24a5c86c1e5eeaae721c6",
"_rid": "9ikLAL9mDQATAAAAAAAAAA==",
"_self": "dbs/9ikLAA==/colls/9ikLAL9mDQA=/docs/9ikLAL9mDQATAAAAAAAAAA==/",
"_etag": "\"00000200-0000-0000-0000-5a1bed1c0000\"",
"family_name": "Green",
"given_name": "Thomas",
"phone_numbers": [
{
"id": "eb8e6d6b6317499c96c568a2b6088101",
"_rid": null,
"_self": null,
"_ts": 0,
"_etag": null,
"name": "private phone",
"number": "564894654"
},
{
"id": "e8ffb8de9d55489cb84d3342189240c1",
"_rid": null,
"_self": null,
"_ts": 0,
"_etag": null,
"name": "work phone",
"number": "654649684684"
}
],
"_attachments": "attachments/",
"_ts": 1511779612
}
...the correct meta-tags for the root object are created upon writing into DocumentDB. Great. But the meta-tags in the child documents are emtpy. I don't need them and obviously DocumentDB does not need them either.
what i ultimately want to be saved to the database instead:
{
"id": "object768f02af46b24a5c86c1e5eeaae721c6",
"_rid": "9ikLAL9mDQATAAAAAAAAAA==",
"_self": "dbs/9ikLAA==/colls/9ikLAL9mDQA=/docs/9ikLAL9mDQATAAAAAAAAAA==/",
"_etag": "\"00000200-0000-0000-0000-5a1bed1c0000\"",
"family_name": "Green",
"given_name": "Thomas",
"phone_numbers": [
{
"id": "eb8e6d6b6317499c96c568a2b6088101",
"name": "private phone",
"number": "564894654"
},
{
"id": "e8ffb8de9d55489cb84d3342189240c1",
"name": "work phone",
"number": "654649684684"
}
],
"_attachments": "attachments/",
"_ts": 1511779612
}
I find it difficult to find information on things related to DocumentDB, the internal workings of Microsoft.Azure.Documents
and am lacking knowledge of the correct terms, so pointers in that direction will be much appreciated.
Upvotes: 0
Views: 235
Reputation: 4994
Microsoft.Azure.Documents.Document documentation states that it
Represents a document in the Azure Cosmos DB service.
It is a special subtype of Resource class and as such it contains the meta-properties that all DocumentDB resource-level objects need.
In your case, by trying to suppress it's Resource-behavior, you are trying to use the type for a scenario it is not intended for. That's always a warning sign to reconsider your design.
Still, what you could do:
Alternative 1: remove default values during serialization
The fields you don't want are using the default values. You can omit such fields from serialized JSON if you want to. You can serialize with custom settings using Document.SaveTo(Stream, SerializationFormattingPolicy, JsonSerializerSettings)
method.
Note that it would also affect other fields in your model with default values. this may or may not be what you want.
Alternative 2: custom model classes
You could consider defining a strongly typed explicit storage model which already contains only the properties you want stored and necessary translation logic between them or to other models. If you don't need those meta-fields then don't include them.
Alternative 3: JObject
You could consider working on Newtonsoft's JObject type instead.
This is just as flexible as Document
, but it would give you full control of the JSON that would end up in your document. Just explicitly remove any undesired phone-number item meta-properties before saving your aggregated document to DocumentDB.
Upvotes: 1