Linq and Entity Framework 7 support about orientdb-net.binary HOT 21 OPEN

Guys, I think that writing LINQ provider to orientdb is an excellent feature that will give .NET developers the ability to quickly start using this database.
I spoke with the development team orientdb and they tell me that SQL syntax changes after release 2.0 which should be soon.

from orientdb-net.binary.

@jersiovic,
Write Linq provider to the orientdb is not easy task at all, special that SQL Parser will be changed in the next releases.
But your idea is very cool, i will leave this issue open and maybe will support this in the feature

from orientdb-net.binary.

Yes to develop a LINQ driver is not easy but you can do it gradually as this guy is doing with MongoD with FluentMongo'.

https://github.com/craiggwilson/fluent-mongo/wiki/Linq

He adds native support LINQ gradually.

I think it would be a good idea you start adding a minimum support to LINQ and while you are busy working in other priorities of OrientDb maybe other people interested like me can send you pull requests supporting more subsets of LINQ.

from orientdb-net.binary.

Related to make a provider for EF7 once you have developed a LINQ provider it shouldn't be difficult to have the EF7 provider. I think you can start using as a base the in memory EF7 provider it includes but instead of saving data in memory you should save data in OrientDB

from orientdb-net.binary.

The whole ASP.Net 5 is focusing on ease of use and interoperability. As I read on the EF7 GitHub page they are relying on re-linq to ease the Linq implementation. They are also providing a sample project for a EF7 provider. Although I would wait till they update the provider implementation guideline. The wiki page clearly states it is out of date. I am currently diving into those matters, so perhaps I'll have a look at it as soon as the guideline is updated.

from orientdb-net.binary.

Sounds good, by the time the EF project might have updated their guidelines as well. Then all parts would be in place.

from orientdb-net.binary.

I can't even fathom how LINQ relates to a graphical model. I would strongly advise against doing a LINQ provider. Steal from LINQ what looks like what will fit and just build a sane querying api likely with fluent chaining. If you actually build LINQ into this, you will spend a never ending number of years hunting down the infinite number of edge cases users will complain about. I could never in sound conscience recommend a person go develop a LINQ provider.

from orientdb-net.binary.

Can you please show samples of some of those edge cases you are talking about?
I use currently Siaqodb an object/document oriented db that offers as its only API a LINQ provider and I haven't find the edge case you are talking about.
I find an object oriented db like Siaqodb and a graph db like Orientdb very related on how they store data, am I wrong?

from orientdb-net.binary.

Dynamic LINQ indeed is a fluent API that offer fluent chaining what is the problem with that? I think that using the same API other dbs use is good to help devs to migrate from one db to other. If LINQ limits you in some way you can enrich your provider with extra functionality to help devs to leverage the characteristics of your concrete db

from orientdb-net.binary.

one one side developing a linq provider is propably one of the hardest things someone can do.
on the other side working with linq and the benefits (refactoring, intellisense, etc.) may be worth the effort.

propably most devs will need for select query purposes on the first instance - insert and update have a much lower priority as these relate to batch updating large sets of documents.

from orientdb-net.binary.

@Chubie,
You absolutely right, current implementation already support fluent API for select statement to.
Look to the this test case https://github.com/orientechnologies/OrientDB-NET.binary/blob/master/src/Orient/Orient.NUnit/Query/SqlGenerateSelectQueryTests.cs

from orientdb-net.binary.

LINQ is _relatively_ straight forward for simple selects and where clauses, but once people start tossing JOIN, AGGREGATE, GROUP BY, UNION, EXCEPT. It's just a never ending set of permutations that may or may not validly exist. LINQ providers work great when they're mapped to SQL Database as there's almost an exact 1:1 relationship between operations (unsurprisingly since LINQ is modeled after SQL).

You just end up with a mine field of combinations that may or may not be supported. LINQ and IQueryable is the leakiest abstraction ever made.

The other big cost to LINQ providers in a nonrelational world is it brings relational baggage. Just because you can physically facilitate JOIN, UNION, etc doesn't mean it actually means any type of sanity in a nonrelational world.

RavenDB supports what would truly be straight up joins, but it's one of the largest things to avoid in RavenDB. It's also not possible to do .JOIN

from orientdb-net.binary.

@dotnetchris
i fully agree with you - of course linq has -- by design -- a strong relationship to sql query syntax.
but on the other hand orientdb has also a sql query syntax and many operations would be portable to linq.
with this feature the client driver gets - imho - usable.
writing queries as formatted strings works obviously in small projects but when projects grow and get more dynamic it get's much more difficult.

we're currently developing a quite large groupware that uses many entities and rely strong on features shared across completely different modules.
at the moment we're using an extended ravendb (enhanced by a quite strong security model) as document store that works quite well.
unfortunately we've to implement some kind of foreign key concept to ensure concistency of the database relationships.

in order to reuse common query clauses depending on client side submitted json filters we're using interfaces and generate additional clauses. this means we need queryables that provide the type of the current queried set (which may change during the query due selections and so on).
for statistical purposes we're using linq2sql - but we can reuse out query filters from the ravendb.

in that point i see a much more flexible point in using linq.
when writing a query i don't want to care about the database itself or the database model in some respect. a good linq provider should translate the most important features into the best database dependend methods.

therefore a suitable linq provider for the requirements in our solution (1 mio lines of codes / around 7 independent modules) just requires a suitable filtering method (where), edge traversal (generating new queryables of another type?) and a good select clause.
when optimising for the database and a special case that has to be really optimized the native syntax may still be used. but in most cases it's important to write stable and maintainable code.
nobody likes to debug systems that break because some inputs have not been escaped correctly.
handling parameters in general is a weak point (a linq abstraction does not help at this point) - i don't want to get back to the times where sql injections have been the favorite way to attack the systems.

from orientdb-net.binary.

@Chubie that's why i'm suggesting that Orient create a LINQ-like syntax for select, where, and other relevant methods, but not encumber itself to try to be a true LINQ provider.

I fully support strong typing all the way. RavenDB aside from having it's LINQ provider also has a strongly typed LuceneQuery Api that is not LINQ but is LINQ-like. I would strongly recommend emulate the LuceneQuery Api of RavenDB, not the full "LINQ"

from orientdb-net.binary.

Well, LINQ maybe is near from SQL however if you take a look with a profiler to what an ORM produces to tranlate LINQ to SQL many times it sucks. So maybe it is not so near as we initially think.
I prefer to see LINQ as a language to manage objects with common operations you usually do with objects. There are operators like JOINS that are very used when you work with a relational db. But there are other more object oriented like INCLUDE that I avoid as much as I can when I work with a relational db because it has an horrible performance. Just the opposite happens when I use an object oriented db (a graph db should be the same). In that case INCLUDE method has a very good performance in comparison to a relational db. Furthermore, WHERE method filtering for properties of related object you didn't INCLUDED or JOINED in your query work very well in comparison to a relational db.

I agree OrientDb can implement a LINQ provider only for select, where, include, and other methods they think this db can give the best performance using native calls (better than a translation to sql that have to be translated to a native call). For other LINQ methods they think the capabilities of the db are not going to provide a better performance or that have a complexity of programming them that are not worth the value they return: They simply can use default implementation of LINQ to Objects instead of offering all the methods as a LINQ to DB implementation.
In fact this is the approach Siaqodb took. Initially they offered support by the db only for a bunch of the LINQ methods they consider a must, for the other methods they simply used LINQ to Objects (this operations were executed with the data in memmory). With the past of the time and hearing the request of the users they have added support for other methods they have find ways to implement improving LINQ to objects performance.

So, if this path is available I would prefer to use a LINQ provider that fits the standard instead of using a LINQ-like provider in order to make my code less dependent of an specific db.

from orientdb-net.binary.

@jersiovic don't ever try to fool yourself. Your LINQ code is 100% coupled to your database. The only rare exceptions is MYSQL vs MS-SQL vs PostGres, maybe just maybe you can get away with cross compatibility. That has to do with the fact they rely on the ANSI SQL standard however and drive through a provider model. That is not relevant to anything else.

Do you really believe you could write a query for OrientDB and have it mean anything on MS-SQL, RavenDB, Couch, or LevelDB? Sure maybe if it's the most basic query in the world: single thing, basic filters; but anything outside of that trivial scenario?

from orientdb-net.binary.

Indeed, currently I'm sharing code between Siaqodb a Nosql db without any sql API and Sql Server through Entity Framwork. How? Through LINQ.An it is not a trivial scenario for sure. I don't say it was easy but I say it has been possible with the help of Siaqodb guys that were very open to close the gap with Entity Framework. The point is now after see the result I would like to see other dbs offer the same LINQ api.

Sql is ok but as it is it is only useful for relational dbs. What you say was true in the past when all dbs were relational. Now with all the new Nosql dbs a new standard oriented to objects is needed or you are happy with a different API for every different Nosql db? By the moment nearest standard available is LINQ.
If RavenDB or other doesn't work with LINQ is only a matter of interest, because if they want they can specially in the conditions I pointed in previous post..

from orientdb-net.binary.

IMHO Linq to Sql is/would be great with OrientDB and doable. You can easily refactor your code when schema is recreated from c# classes. Far more better experience than producing sql string or fluent interface. You can also detect where your fields are used, queried,set and so on.
Prefetchable objects or edges could work incredibly good with lambdas but you have to introduce "views" properties for edge labels.
I did some attempt in my company with internal driver to implement something close and following queries work like charm.

// prefetchable objects may work like here
var df2 = db.Query<Film>().Where(t => t.Budget == film.Budget).SelectWithPrefetch(t => t,t=>t.Cast);

var travoltaJohn = db.Query<Actor>().Where(t => t.FirstName == "John" && t.LastName == "Travolta").FirstOrDefault();

var df5 = db.Query<Film>().Where(t => t.TheMostFamousAward.Year >= 1990 && t.Genres.Contains(film.Genres[index])).Flatten( t=> t.References.ToRecords());

var df7 = db.Query<Film>().Where(t => (t.StarringActorsCount > 0) || (t.Budget != 0)).Flatten(t => t.TheMostFamousAward.Who).OrderBy(t => t.LastName).Take(2).Skip(1);

var df = db.Query<Film>().Where(t => t.Colorful == true).Select(t => new { BudgetClone = t.Budget, AnotherVar = t.Colorful });

from orientdb-net.binary.

Linq would be a awesome idea ! The current syntax is quite difficult

from orientdb-net.binary.

Yes, it would be wonderful, we considering move from Mongo, but we used linq in its' simplest form i.e.
r=> r.Application=model.Id but in so many ways that nobody would want to rewrite that

from orientdb-net.binary.

Has anyone considered supporting Gremlinq? https://github.com/Loupi/Frontenac/wiki/Gremlinq

From the description: "Gremlinq is a Blueprints ORM and graph traversal language based on Gremlin and LINQ."

Gremlinq is part of Frontenac (Blueprints implementation for .Net). Support for Frontenac in OrientDB would be great.

from orientdb-net.binary.