Support for Document Databases in General

[craiggwilson]

I saw that there was a ticket for including support for DocumentDB. I hacked around today building a MongoDB provider. I haven't tackled queries yet, just the save changes stuff which all works great when the entity is flat - no nested documents or nested arrays in json speak.

So, it doesn't seem like there is any support for tracking changes in nested documents/nested arrays when they don't have a key. For a document database, these aren't relationships in the foreign key sense, but more of a parent-child in structure. I began attempting to use a Sidecar for this (like the RelationshipsSnapshot) and overriding the ChangeDetector to use it but found that I still need to be able to get a StateEntry in order to determine whether changes have been made to a nested entity. However, StateManager can only do that when a key has been defined. Ho, hum... It seems like 1 or 2 concepts are missing in the existing Metadata related to handling embedded classes/dictionarys and arrays/lists that don't exist in a separate table (or collection). This is obviously only useful for those providers able to handle this type of thing, but the same could be said about ForeignKeys only being relevant for providers able to handle relationships.

Let me know your thoughts. I'm excited about EF7 opening up to allow this type of integration and hope I'll be able to get something working.

Thanks, Craig Wilson

[anpete]

cc @smitpatel

Hi Craig,

Thanks for your interest in EF7!

I think you are right that we are lacking the correct abstractions for dealing with these kind of containment relationships in EF. One thought we had early on (and I think this is similar to some of the first things you tried) was that we could synthesize FKs for these types of graphs and that one advantage of this would be a uniform way of representing things. As you have observed, FKs in EF are first-class and not just a way of modeling relational stores - we chose to use them because they are a simple and powerful way to model associations, and also work well for other things such as disconnected graph behaviors. E.g. When round-tripping data to a browser client.

That said, we haven't had a chance to validate our thinking about this yet. @smitpatel on our team is currently investigating what Mongo support would look like and it would be great to have community involvement in uncovering the right way for EF to do this.

One additional thought that springs to mind is that these containment relationships appear to be very similar to value objects (Complex Types in EF6) - A feature we haven't added yet but know we need to. I wonder whether we can have an abstraction for containment that deals with both of these things?

Cheers,
Andrew.

[craiggwilson]

Thanks for the reply. Yeah, I think there is a lot of stuff that could be done with FKs in the general sense. It's just that the current requirement includes an key field, where as a containment type's identity is derived from it's parent.

I'd love to work with you guys on this. We (MongoDB) are getting close to finishing up our next major version (2.0) of the .NET driver and have split out a core piece that is much nicer to work with when building an alternative API like EF. My email is craig.wilson at mongodb.com, so let me know if there is anything I can do to help out.

[divega]

Moving straight to our backlog as we are not going to make much progress in this area for EF7 RTM, but it still of high importance after that. Also following up with Craig on email.

[smitpatel]

Duplicate of #8443 ?