DocumentDB Provider

[SychevIgor]

In EF7 will be Redis and Table Storage support. I think that DocumentDB support would be a great option both for EF 7.1 and DocumentDB

It's not a bug, it's some sort of feature request/idea.

[rowanmiller]

Agreed this would be good to do. It will probably come after the initial release of EF7 so moving to our backlog for the moment.

[dcinzona]

+1

[serkanpektas]

+1

[janus007]

Seems weird to have an ORM to support Redis. Why support anything else than proven technologies? This year Redis, next year RavenDB, and why not ElasticSearch, and next year EF 8 supporting Redis but only for backward compability.

Watch out guys, don't try to create a World-ORM ; WORM, new acronym :), that is going to get so big that it is impossible to maintain, would be a pity to see EF7 as yet another WORM to avoid, right?

What happened with the module/ plugin based - approach, that would be a much more modern way?

-1

[serkanpektas]

@janus007 Using EF7 Core APIs, it is possible to create a provider (Module.Plugin based) for additional data store types.

Have a take look at the design documents Entity Framework Provider.

[matas-vaitkevicius]

+1

[afoliaco]

+1

[DavidBurela]

+1

[andriysavin]

I'd like to put my two cents on this from the DDD (Domain Driven Design) perspective. As well known, ORMs are must have in DDD, since they allow not only to separate object model from persistence details, but also to track changes so that business code contains almost nothing but object model manipulation. Also, document databases fit very naturally into DDD concepts (like Aggregates) as persistence technology. With that said, IMHO the most natural combination is ORM (ODM)+Document database (be it MS DocumentDB or MongoDB). I understand that SQL databases still dominate and probably will, so SQL providers are №1 priority. But then some document database provider should follow, and its strange that its not included in the first release in favor of Redis or even Table storage.

[ErikEJ]

@andriysavin Neither Redis nor table storage will be in version 1.0

[andriysavin]

@ErikEJ Now I feel better! :D

[heldersepu]

+1

[gmfx]

+1

[bjorn-ali-goransson]

+10

[janus007]

Nice to hear that Redis is dropped.

[gdoron]

@janus007 It's funny that you find DocumentDb to be more important than Redis. Just as a reference http://db-engines.com/en/system/Microsoft+Azure+DocumentDB%3BRedis

Seems weird to have an ORM to support Redis. Why support anything else than proven technologies?

Calling Redis a not proven technology... .

[janus007]

@gdoron , I think you misunderstood me. When I say proven technologies I don't mean that Redis is not proven, nor RavenDB or MongoDB. My point is that EF is an ORM, remember the acronym :) Why map anything when using a document storage? An ORM is for mapping a relational world, the idea is to keep it simple. Some even argue that it should be so simple that new developers can have a data storage without knowing anything about SQL (pun intended).

My worries about EF is that it is going to be yet another monstrous enterprise flagship that supports a trillion storage providers. EF 7 should imho be kept simple and extendable/ plug-able/ open sourced.

If Redis or supporters think EF 7 is a viable choice then go ahead, make a plugin for it, but keep Microsoft out of the picture.

[andriysavin]

@janus007 There is another, more correct term for that - ODM. It doesn't make much difference how exactly its called, main idea is the same. Regarding you worries: its EF7's flexibility and extencibility what allows adding functionality such as ODM for DocumentDB without making the main EF libraries havier. You don't need it - you don't plug it in.

[roji]

@janus007 note that supporting non-relational databases (e.g. document stores) is a primary goal for EF Core, so much so that the entire framework is split internally between a core and an additional relational add-on (see the two nugets).

Also, as @andriysavin says, supporting another provider doesn't necessarily make EFCore any less simple/pluggable/open source.

[bjorn-ali-goransson]

Why map anything when using a document storage?

@janus007 , we need to map it to CLR properties in POCOs, so EF could help out here.

Clearly you need to read up on NoSQL technologies. You seem critical in a way that was merited only in the very early stages of NoSQL. Read this quite critical but also realistic article on NoSQL to learn more: http://martinfowler.com/nosql.html

Also, NoSQL databases are not about excluding SQL, again you are talking much more than reading. Read this: http://martinfowler.com/bliki/NosqlDefinition.html

May I add that I'm not a NoSQL "fan" of any sort, I've never really used them in practice. I only use relational databases professionally.

[janus007]

@bjorn-ali-goransson, it is not my intention to sound critical about NoSql. I think document databases are very interesting and surely has their eligibility over SQL in some/ many cases.

Thank you for clarification regarding EF 7 primary goals.

I'm sorry to hear that you say I'm talking more than reading, I will think about that.. thank you.

[bjorn-ali-goransson]

Hope I did not come across as over-aggressive here. I just wanted to neutralise some over-negativity. :-)

Also, from your comment about W-ORM, it seems you are not using NuGet yet? It's really a very nice way to plug-in functionality into your .NET applications.

(For what it's worth, I find the thought of an Elasticsearch provider for EF very exciting :tada:)

[janus007]

@bjorn-ali-goransson, I know the feeling :)

I use NuGet as much as I can and I admit I was a bit disappointed when Microsoft abandoned their JSON project file. As a very old DBA (since 1998 where we wrote SQL by hand), I actually like the ORM-concept in minor doses, interestingly enough I have tried to make as much data as possible JSON-like (depending on the nature of the beast of course) and store JSON as varchar and then late bind it... hmm.. ;) If EF without any overhead can help with that it would be a welcome future.

Haven't had the opportunity to work with ElasticSearch, just tested it a few times after I deployed a docker-package. And yes... couldn't agree more, it would be of tremendous value if EF 7 could handle that just by getting a NuGet-package.

Cheers

[ikourfaln]

+1

[SiqiLu]

+1

[galvesribeiro]

Hey guys, would there be any efforts from Microsoft on this particular issue or can community contribute a provider for DocumentDB and it would be accepted as a PR? Its almost an year without activity on this issue.

[gdoron]

I'm curious why would you use EF instead of documentDb SDK (or Redis). EF won't have support for many features, like subscriber, fire and forget, replication (Redis examples).

[ErikEJ]

@galvesribeiro a beta mongodb provider that also works with documentdb is available

[galvesribeiro]

@gdoron just for the same reason you would use ADO.Net instead of use RAW SQL against the underlying database engine driver. Abstraction. Just to name one reason.

@ErikEJ MongoDB support on document DB does not support 100% of the DocDB APIs. It is a migration path, not suppose to be used forever if you can change to use the native SDK.

[gdoron]

Well I guess EF won't support 100% of the API neither so I'm not sure why you are waiting for an EF provider. It's like using IDistributedCache instead of Redis SDK, technically you can use it, but you're limiting the number of features you can use drastically.

[divega]

Closing this as a duplicate of https://github.com/aspnet/EntityFramework/issues/8443 which is about a CosmosDB provider. We can reactivate later if DocumentDB APIs end up not being covered and if they remain a goal.