Open ajcvickers opened 1 week ago
We will provide a mechanism to go back to the old behavior
Just for completeness, mentioning @divega's additional suggestion of allowing users to integrate a discriminator into id
, but one that's the same across the inheritance hierarchy (i.e. the root type's only), as opposed to the discriminator property that differs across entity types within the hierarchy. The reason to do this is that it would allow using ReadItem; with concrete discriminators, we don't know in advance what concrete type we're getting (which kind of Blog), so if the concrete discriminator is part of id
, we can't use ReadItem.
Motivation
Currently we have a lot of rules that determine which properties get configured as keys, partition keys, alternate keys, discriminators, and do on. The intention here is to create a model that will fall into the pit-of-success for use with Cosmos. This works to some extent, but the problem is that it becomes very hard to follow what is actually happening, or why. This means that, for example, that it is difficult to know which properties form a relatively simple concept such as the JSON
id
property. And without knowing the definition of theid
, everything else becomes confusing.Proposal
Remove a lot of the magic from this area to create conventions that are easy to understand, while allowing additional configuration to be done explicitly, also in a non-magical way.
Principal
Based on discussions with the Cosmos folks, we will use the following principle:
Id
discovered by convention should map 1:1 to the JSON id property, unless the developer explicitly configures something different.Notes:
Discriminators
id
property will not have a discriminator added so as to keep it an easy-to-understand 1:1 mappingNote that partition keys will still be added to the EF primary key definition.
id
id
. If this part is calledId
then this is stillId
toid
mapping.