Why not joining the forces with Vita ;)

Aug 5, 2015 at 8:54 AM
Edited Aug 5, 2015 at 8:56 AM

I stumbled upon your library while researching different options for locally persisting object graphs (looking for ESENT wrappers in .NET). I think one important obstacle for .Net developers to pick ESENT is the totally different API they need to learn in comparison to other options they have (and it's a bit verbose too). I know a nice open source ORM library which I personally prefere to Microsoft's EF since it's much lighter and in some cases more powerfull. It currently supports SQL, MySQL, SQLCE. It might be good idea to implement a new ESENT provider for Vita with the knowledge and experience you have. you can have a look at Vita here

Aug 5, 2015 at 4:10 PM
Hi Reza.
I’ve took a brief look at that Vita.
To me, it looks like the whole framework is built around the higher-level SQL abstraction.
If you’re OK with the costs of that higher-level approach, you don’t need ESENT.

Design of SQL and ESENT is fundamentally different.
SQL is a query language for relational databases. ESENT is API for storing/updating unrelated records.
If you need to build complex queries with Linq2Sql, or you want the DB engine to verify your foreign keys — you need SQL database.
If you need to update 50k small records each second, or you want to store key-blob pairs with minimal overhead — you need ESENT.
If you do not have either constraint, choose whatever you like.

Technically I might be able to implement something SQL-like on the top of my ESENT serialization. Two problems: (1) it’s a lot of work, and I’m not willing to do it for free (2) I doubt I’ll be able to exceed the performance of intentionally-built SQL implementations such as SqlCe or Postgres, so it will be no real value using ESENT instead of an RDBMS.