EF Core

[gar-ema]

From @esamk on August 16, 2017 7:50

I am not quite sure if this is the right place to talk about this, but here goes.

Did you ever consider creating EF core database provider instead of a stand-alone driver as per this discussion:

https://github.com/orientechnologies/OrientDB-NET.binary/issues/9

Being able to use OrientDb through Entity Framework would mean, IMHO, a huge boost for developer productivity.

If you did consider the EF option at some point, could you elaborate on what made you decide against it?

Copied from original issue: orientechnologies/OrientDB.Net.Core#14

[gar-ema]

From @realityenigma on August 16, 2017 23:2

Don't mind the questions at all. The current architecture does not preclude integrating into EF Core and I've actually thought about at least getting a linq provider added. Now as to why it is currently structured the way it is; simply put, we wanted to reuse as much code as possible while working towards a more modular architecture. I hope that answers your question and I never mind answering more.

[gar-ema]

From @esamk on August 17, 2017 5:55

realityenigma,

Glad to hear that. Do you accept pull requests? And if you do, do you have documentation that would allow others to think about what they might be able to contribute? For example, how do you plan to split the functionality into modules? What are the required/optional modules? What are their responsibilities/interfaces? And so on.

[gar-ema]

From @realityenigma on August 18, 2017 2:6

I will absolutely accept solid pull requests! I will take some time to develop an effective roadmap and would be open to suggestions with that as well.

[gar-ema]

From @esamk on August 18, 2017 6:14

Awesome. I am currently experimenting with a minimal Linq to orient dB SQL translator for querying. At this point, we're limiting ourselves to Linq-method syntax, ie. query = context.someentities.where(e => e.foo == "bar").select ... which produces an expression tree (query). Then we take the expression tree and translate it to an orient dB SQL.

Our ExpressionTree -> SQL translation is simply an implementation of an interface method doing ExpressionTree -> string conversion. So, it could be replaced by a Gremlin translator or what have you. This code also fits well, AFAIK, to EF core provider architecture.

The other part of our experiment is the database context and a generic IEntitySet. However, we don't do caching, entity proxies nor any other fancy stuff at this point. Just bare minimum. This is not EF core compatible code (the EF does these things for you).

We have discussed an improved (in comparison to the old .net driver) schema mapper (c# types -> schema) and some other parts as well, but we'll see where that goes.

However, when it comes to the query translation, I'd be happy to contribute once the code is mature enough.