search

BlueshiftSoftware / EntityFrameworkCore

NoSQL providers for EntityFramework Core
Other
281 stars 57 forks source link

consider ef 1,1 provider #3

Closed ErikEJ closed 7 years ago

ErikEJ commented 7 years ago

So it will be easy to use today

crhairr commented 7 years ago

I considered it, but the provider is still in a very early alpha state. The provider works and communicates with MongoDb instances fine, but there are still issues with ComplexType support and how the state manager handles those properties. A 1.1 provider will not fix that, and may cause problems with large-scale projects. Until ComplexTypes are properly supported, I want to keep this as an alpha release so that users really consider whether or not to consume it in their applications. And if it's going to be alpha it may as well build upon the latest EFCore preview builds.

ErikEJ commented 7 years ago

Makes sense!

crhairr commented 7 years ago

There seems to be a good bit of interest in a 1.x provider, so I'm reopening this issue to look into back-porting the code.

ErikEJ commented 7 years ago

I vote for not doing this, as the 2.0-preview1 bits will be available on Nuget.org in less than 2 weeks at //BUILD

crhairr commented 7 years ago

I see your point. Since EFCore-MongoDB is going to be in preview until complex types are supported anyway, than anyone wanting to adopt it would have to be willing to use prerelease code in the first place.

However, EF Core 2.0 isn't scheduled for release until Q3. If I can put in a little effort and produce some 1.x-compatible pre-release packages, then I can at least help some users adopt EFCore-MongoDB over the next few months. So, I'm still going to look into what it will take, but if it's too much effort I'll just close this again and go back to urging users to upgrade to 2.0.

crhairr commented 7 years ago

Closing this. EF Core 2.1 is out now, and I'll be looking into whether or not "Owned Types" will properly satisfy MongoDB's complex type requirement.