Linq To Cypher

[Javier Ruiz Aranguren]

Andrés Taylor, in his really interesting Webinar Cypher for SQL professionals, has told us that he doesn't know about a complete implementation of a Linq To Cypher provider.

I think it would be a very interesting thing to the community and I would like to know if any of you would be interested in participate in developing a project to build a Linq to Cypher/Neo4j client, or whether you know about any effort in this direction.

Regards.

[Aran Mulholland]

Neo4jClient has this - http://hg.readify.net/neo4jclient/wiki/Home

The implementation is still under development, but there is great stuff on the Issue-45 branch, I can use it to craft every query that I have needed (so far)

--
 
 

[Tatham Oddie]

Hi Javier,

 

It doesn’t make a lot of sense to map Cypher directly on to LINQ. (At least, not to me.)

 

We have a very very LINQ like set of signatures in Neo4jClient, which work basically the same way. It’s just not implemented as IQueryProvider under the covers. We still return an enumerable that only executes over the wire when you touch it, and we compile your query down to native Cypher.

 

As Aran mentions, there’s some nice stuff on the issue-45 branch that’s about to land into the default branch soon, and then be available in the official NuGet package.

 

We discuss the Neo4jClient on neo4j...@googlegroups.com.

 

 

-- Tatham

--
 
 

[Javier Ruiz Aranguren]

Thanks, @Aran, and @Tatham. 

Yes, I knew your proposal (which I plan tu use :-), but in the mid-term I think there is room for a Linq2Cypher. I think make sense, probably influenced by Erik Meijer article in CACM.

Perhaps it should have a set of extensions specifics to graphs, but I wouldn't reject it so fast.

Why do you think it does not make sense? I guess you thought about this when implementing Neo4jClient

Regards.

[Tatham Oddie]

Javier,

 

What are you trying to achieve?

 

We wanted:

 

·         Lazy enumerables

·         C# expressions for predicates

·         Rich design-time support

·         Typed queries

 

We have all of that, without trying to bash it in to IQueryProvider. The surface layer you experience feels exactly like LINQ-with-graph extensions, it just isn’t implemented that way.

 

The problem with IQueryProvider is that we have to map the graph model on to it. RETURN becomes Select. Group by as different semantics. The order of clauses doesn’t match in C# vs Cypher, so now we start building an object model for a query. When we do that START, MATCH, WHERE, MATCH, CREATE UNIQUE, RETURN, WHERE clauses don’t make sense – because they all come in a different order that the object model can’t represent. The list goes on. These all seemed like hard problems to solve, that just deviated away from Cypher, but added absolutely no consumption benefit. Instead, we delivered all of the benefits of LINQ, just without using an IQueryProvider. The API is consistent.

 

A major design goal for us was to be respectful to Cypher. This keeps the code leaner and the learning curve lower. You can take a Ruby post about Neo4J and almost copy-past the Cypher in to C#. Some minor syntactic tweaks and you’re away.

 

If you ignore the implementation details underneath, what does LINQ have that we don’t? :)

--