ESENT database provider

[Opiumtm]

Provide Entity Framework 7 provider for a ESENT NOSQL database. This database is officially supported on UWP platform, but now there is only ISAM imperative access to ESENT DB in C#.

ESENT is proven as very fast, stable and reliable NOSQL database, and it is supported in UWP apps. It's a good alternative to SQLite on UWP platform. But ESENT lacks any high-level API, it have only low-level imperative C++ style APIs for C#.

[jnm2]

Wow at this conversation! My respect for the EF team just went up tenfold.

To get all the way back on topic, I would love to see ESENT as a provider but I'm not sure what the difficulty level would be to implement it. Is anyone currently planning on doing this or should I start poking around when my schedule clears a bit?

[Opiumtm]

@jnm2 I think, SQL providers are more difficult to implement than NoSQL providers. With ESENT challenge would be to integrate all ESENT benefits and optimizations within Entity Framework. For example, ESENT support some specific concepts like "pre-joined tables" and "tuple indexes". Also, ESENT model is very different from SQL and document oriented NoSQL. Additional challenge is to develop ISAM compatible layer. ESENT is a very advanced transactional relational storage engine, which is decoupled from SQL query language (it's not a database product, it's a foundation for database engines and is used as it by RavenDB, for example). So, ESENT is a very special case - it gives Entity Framework unique opportunity to build object-oriented persistence directly over an advanced data storage layer without SQL language overhead and its shortcomings. ESENT is ideal foundation for first-class object-oriented data storage transactional engine without any intermediate abstractions.

[ErikEJ]

@jnm2 : I am thinking about doing something, but as stated earlier, I think awaiting a NoSQL provider implemented by the EF Core team itself would in my opinion be a very good idea, to save a lot of effort.

@Opiumtm :

I think, SQL providers are more difficult to implement than NoSQL providers

I disagree, with all the work done in the core relational ef component, I believe it is actually quite simple to implement a ANSI SQL based provider - and there is currently no sample NoSQL provider implemented based on the current codebase. - And you appear to be repeating yourself for no reason...

[SleepyDeb]

SQL Query Languanges sucks, binary is the way

[Opiumtm]

@ErikEJ after all, Entity Framework Core design notes state that NoSQL providers would be supported as first-class citizens. But in reality, EF Core provide very limited NoSQL support and as I can assume, EF Core architecture and codebase was made with SQL in mind and lack proper infrastructure to support NoSQL.

[rowanmiller]

@Opiumtm we prototyped providers for Azure Table Storage and Redis as we were building out EF Core, to make sure that main components weren't relational specific. Everything relational is split out into a separate package that each relational provider builds on. We also have the InMemory provider, which is somewhat simplistic, but not a relational provider.

That said, we fully expect that as providers for non-relational stores are built they will drive some changes in the central EF Core components to address things we didn't think of.

[Opiumtm]

I have executed some benchmarks of embedded DBs for UWP platform.

On Intel Core i7 Windows 10 Desktop PC, ESENT shows much better performance than SQLite. These results are very important too for resource constrained handheld devices or IoT.

Bulk DB inserts inside transaction: SQLite: ~60 microseconds/insert ESENT: ~15 microseconds/insert

Bulk random record searches by primary key: SQLite: ~30 microseconds/search ESENT: ~3 microseconds/search

These benchmark results are self-explanatory.

And these outstanding performance results for ESENT are accompanied by ESENT's snapshot transaction isolation, high fault-tolerance, practically unlimited scaleability, rich feature set (SQLite's feature set is virtually non-existent if compared with ESENT feature set).

[ErikEJ]

@opiumtm Looking forward to your 3rd party provider!

[Opiumtm]

@ErikEJ I have tested DBs performance using low-level APIs for each DB provider. So, no ORM was used. Just plain SQL commands for SQLite and raw ManagedEsent invokes for ESENT.

As far as I know, there is no EF provider exists for ESENT. Personally I have reasonable experience with raw ESENT APIs (using ManagedEsent lib) and have used ESENT this way in some of my projects, but have minimum knowledge about EF internals and how to develop DB providers for EF.

[sandorfr]

Back in the days I wrote some quick and dirty prototype for e LINQ QueryProvider and GenericRepository for esent. It's far from being production ready and making a good quality EF provider will be a much bigger job anyway. If anyone wants to tackle this I can share this code (I personnally would be more inclined to work on LiteDB)

[ajcvickers]

Closing this as we do not plan to implement and maintain a ESENT provider for EF Core. However, we would be supportive of a community effort to create such a provider.