Re: [Neo4j] Cypher->Pickle?

[Javier de la Rosa]

IMHO, the differential key of Cypher regarding to SQL, is the way in
which Cypher builds the "joins". I mean, the clause PATTERN or WHERE
written like "lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor" is pretty
powerful. The rest of the details are unimportant, in the sense they
already have an equivalence in SQL. So, I think to use SQL-like
queries could attract more people interested in Neo4j. And at the same
time, this people will discover the versatility of the Cypher JOINs.

Regards.

On Sat, Nov 5, 2011 at 10:33, Nigel Small  wrote:
>> newbies may find it helpful to start with something they already know.
> One problem with this is that it could invoke a tendency to try to map
> relational concepts onto a graph db. The two types of database are
> fundamentally different at the lowest level and if one starts off by
> thinking "where do I put my 'tables'?" they are only heading down the wrong
> path. I mentioned a while back that I felt designing a graph database is
> more akin to OO design that to relational design. Maybe we should stop
> using the word "database"?? :-P
> *
> *
> *Nigel Small*
> Phone: +44 7814 638 246
> Blog: http://nigelsmall.name/
> GTalk: ni...@nigelsmall.name
> MSN: nasm...@live.co.uk
> Skype: technige
> Twitter: @technige 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>
>
>
> On 5 November 2011 14:03, Axel Morgner  wrote:
>
>> People already familiar with graphs seem to love the original Cypher
>> syntax while newbies may find it helpful to start with something they
>> already know.
>>
>> What about letting both coexist peacefully?
>>
>> Axel
>>
>>
>> Am 05.11.2011 14:29, schrieb Andres Taylor:
>> > On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>> >> I really don't want Cypher to pander to SQL. Cypher is about graph
>> > matching and should be awesome at it
>> >
>> > PQL isn't any different in this aspect. Mattias' ascii-art is still the
>> way
>> > to describe your pattern. Cypher is already very like SQL in many ways -
>> > PQL is a way to acknowledge these similarities and turn them into a
>> selling
>> > point instead.
>> >
>> > Andrés
>> > ___
>> > Neo4j mailing list
>> > User@lists.neo4j.org
>> > https://lists.neo4j.org/mailman/listinfo/user
>>
>>
>> ___
>> Neo4j mailing list
>> User@lists.neo4j.org
>> https://lists.neo4j.org/mailman/listinfo/user
>>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Javier de la Rosa
http://versae.es
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Nigel Small]

> newbies may find it helpful to start with something they already know.
One problem with this is that it could invoke a tendency to try to map
relational concepts onto a graph db. The two types of database are
fundamentally different at the lowest level and if one starts off by
thinking "where do I put my 'tables'?" they are only heading down the wrong
path. I mentioned a while back that I felt designing a graph database is
more akin to OO design that to relational design. Maybe we should stop
using the word "database"?? :-P
*
*
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 5 November 2011 14:03, Axel Morgner  wrote:

> People already familiar with graphs seem to love the original Cypher
> syntax while newbies may find it helpful to start with something they
> already know.
>
> What about letting both coexist peacefully?
>
> Axel
>
>
> Am 05.11.2011 14:29, schrieb Andres Taylor:
> > On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
> >> I really don't want Cypher to pander to SQL. Cypher is about graph
> > matching and should be awesome at it
> >
> > PQL isn't any different in this aspect. Mattias' ascii-art is still the
> way
> > to describe your pattern. Cypher is already very like SQL in many ways -
> > PQL is a way to acknowledge these similarities and turn them into a
> selling
> > point instead.
> >
> > Andrés
> > ___
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
>
>
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Axel Morgner]

People already familiar with graphs seem to love the original Cypher 
syntax while newbies may find it helpful to start with something they 
already know.

What about letting both coexist peacefully?

Axel


Am 05.11.2011 14:29, schrieb Andres Taylor:
> On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>> I really don't want Cypher to pander to SQL. Cypher is about graph
> matching and should be awesome at it
>
> PQL isn't any different in this aspect. Mattias' ascii-art is still the way
> to describe your pattern. Cypher is already very like SQL in many ways -
> PQL is a way to acknowledge these similarities and turn them into a selling
> point instead.
>
> Andrés
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user


___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Andres Taylor]

On Nov 5, 2011 1:51 PM, "Jim Webber"  wrote:
>
> I really don't want Cypher to pander to SQL. Cypher is about graph
matching and should be awesome at it

PQL isn't any different in this aspect. Mattias' ascii-art is still the way
to describe your pattern. Cypher is already very like SQL in many ways -
PQL is a way to acknowledge these similarities and turn them into a selling
point instead.

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Jim Webber]

+1 I love Cypher's ASCII art, and Josh's idea of drawing Cypher inside a 
whiteboarded graph is wonderful.

I really don't want Cypher to pander to SQL. Cypher is about graph matching and 
should be awesome at it - its duty to us newbies is simply to be humane not 
identical to what I (think I) already know.

Jim

On 5 Nov 2011, at 03:48, jadell wrote:

> 
> Mattias Persson-2 wrote:
>> 
>> 2011/11/4 maxdemarzi <maxdemarzi@>
>> I'd say the strongest part of Cypher is the "ascii art" pattern where you
>> clearly see what you're querying for, right there and then without having
>> to parse it into a graph into your head. Removing that would reduce my
>> interest in this language significantly.
>> 
> 
> This! A thousand times this! Whenever I'm trying to explain how you find
> connected information without joins, people's eyes tend to glaze over until
> I a) draw the graph on the whiteboard, b) write out the Cypher query
> *directly inside the graph*. That's the "no f-ing way!" moment for most
> people to see the power of graphs and graph query languages. 
> 
> -- Josh Adell
> 
> --
> View this message in context: 
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481871.html
> Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[jadell]

Mattias Persson-2 wrote:
> 
> 2011/11/4 maxdemarzi <maxdemarzi@>
> I'd say the strongest part of Cypher is the "ascii art" pattern where you
> clearly see what you're querying for, right there and then without having
> to parse it into a graph into your head. Removing that would reduce my
> interest in this language significantly.
> 

This! A thousand times this! Whenever I'm trying to explain how you find
connected information without joins, people's eyes tend to glaze over until
I a) draw the graph on the whiteboard, b) write out the Cypher query
*directly inside the graph*. That's the "no f-ing way!" moment for most
people to see the power of graphs and graph query languages. 

-- Josh Adell

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481871.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[jadell]

This! A thousand times this! Whenever I'm trying to explain how you find
connected information without joins, people's eyes tend to glaze over until
I a) draw the graph on the whiteboard, b) write out the Cypher query
_directly_inside_the_graph_. That's the "no f-ing way!" moment for most
people to see the power of graphs and graph query languages.

-- Josh Adell

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481868.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Michael Hunger]

I also strongly agree. In my discussions with interested people and customers 
this always stood out when pulling cypher to query their data.
They could instantly recognize which parts of their structure are taking part 
in the query.

Michael

Am 04.11.2011 um 21:36 schrieb Tero Paananen:

>> I'd say the strongest part of Cypher is the "ascii art" pattern where you
>> clearly see what you're querying for, right there and then without having
>> to parse it into a graph into your head. Removing that would reduce my
>> interest in this language significantly.
> 
> I strongly agree with this. It's EASY to see the relationships and
> their direction with the syntax right now.
> 
> (cani)<-[:HAS]-(more)-[:CHEEZ]->(burger)
> 
> I glance that and instantly figure out what it's trying to say. The SQL-
> like examples I've seen so far aren't coming even close, IMHO. And
> as the query complexity increases, I think the advantage Cypher's
> syntax has increases even more.
> 
> Additionally I don't find adding a join keyword to a query language that
> queries a data store that has no joins better in any shape or form.
> 
> -TPP
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[maxdemarzi]

Andres Taylor wrote:
> 
> Love the idea. Why didn't I think of that? All of Cypher is made out of
> bits and pieces that I've stolen from others anyway - I think I want to
> steal this one too.
> 

Ha!


Max De Marzi wrote:
> 
>  That is one way of looking at it, another way of looking at it is that
> all the tables are already joined.
> 

I stole that last quote from Marko.  He was explaining Neo4j to the type of
guy who may be making making that buy it or not decision (60 year old
Director of IT, 30 years working with relational databases under their
belt).  When Marko said, "it's like a relational database where all the
tables are already joined", I saw the guy's eyes light up.  *Oh... I get it
now.*  

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481320.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Andres Taylor]

On Fri, Nov 4, 2011 at 10:17 PM, maxdemarzi  wrote:

>
> Tero Paananen wrote:
> >
> > Additionally I don't find adding a join keyword to a query language that
> > queries a data store that has no joins better in any shape or form.
> >
>
> That is one way of looking at it, another way of looking at it is that all
> the tables are already joined.
> Not sure how we can say a graph database "has no joins".
>
> Now, we don't have to throw out anything.  If this is pie in the sky talk
> anyway, we can have it both ways.
> (1) lucy-[:ACTS_IN]->movie
> (2) lucy-[:ACTS_IN]-movie
> (3) lucy<-[:ACTS_IN]-movie
>
> (4) lucy out(:acts_in) movie
> (5) lucy both(:acts_in) movie
> (6) lucy in(:acts_in) movie
>
> What I like about spelling out the relationship direction is:
> A. You avoid typo errors.  Was it -- or ->, look how close 1 and 2 are.
> B. You know right away which direction you are going.  Compare 1 and 2, vs
> 4
> and 5.  At the 6th character in both 4 and 5, you know which direction it
> is.  You have to get to the 17th character in 1 and 2.
> C. We read left to right so:
> -- 1 reads: lucy via relationship acts_in outgoing to movie,
> -- 2 reads: lucy via relationship acts_in both to movie
> -- 3 reads, lucy incoming via relationship acts_in to movie
> That is inconsistent.
> Try:
> -- 4 reads, lucy outgoing via relationshp acts_in to movie
> -- 5 reads, lucy both via relationshp acts_in to movie
> -- 6 reads, lucy incoming via relationshp acts_in to movie
> D. try (a)-->(b)-->(c)-->(d)--(e)-->(f)-->(g)   #did you catch the both
> relationship between d and e?  or did your eyes scan over it?  If you're
> debugging someone else's code, was it a typo or did they intend it that
> way?
> If you spell it out there is no ambiguity.
>
> Anyway, if the --> syntax is polarizing (as it seems to be) then *give
> people the choice* to use whichever they prefer.


Love the idea. Why didn't I think of that? All of Cypher is made out of
bits and pieces that I've stolen from others anyway - I think I want to
steal this one too.

Being able to have these discussions with our users is a luxury that I'm
very happy about - thank you!

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Andres Taylor]

On Fri, Nov 4, 2011 at 8:58 PM, KanTube  wrote:

> At first glance i like the new syntax.  I am a bit confused on Andres
> comment
> that PATTERN is a new construct and is not replacing WHERE.


I'll use old-school Cypher to illustrate my the difference here. Cypher's
MATCH clause is PQL's PATTERN.

Semantically, START, MATCH and WHERE in Cypher represent the same concept.

START a = node:idx(key = "value")
MATCH a-[r]->b
WHERE r.foo = "bar"
RETURN b

This could just as well be expressed like this:

WHERE a = node:idx(key = "value") AND a-[r]->b AND r.foo = "bar"
RETURN b

The reason I separated them is for a pedagogical reason - I think the
structure that Cypher forces on you helps you think and reason about the
query better than the shorter all predicate version. I hope that makes
sense, and that I haven't messed up my assumptions. Btw - I'd love feedback
on this idea - it's a core part in my mental model designing this language.

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[maxdemarzi]

Tero Paananen wrote:
> 
> Additionally I don't find adding a join keyword to a query language that
> queries a data store that has no joins better in any shape or form.
> 

That is one way of looking at it, another way of looking at it is that all
the tables are already joined.
Not sure how we can say a graph database "has no joins".

Now, we don't have to throw out anything.  If this is pie in the sky talk
anyway, we can have it both ways.
(1) lucy-[:ACTS_IN]->movie
(2) lucy-[:ACTS_IN]-movie
(3) lucy<-[:ACTS_IN]-movie

(4) lucy out(:acts_in) movie
(5) lucy both(:acts_in) movie
(6) lucy in(:acts_in) movie

What I like about spelling out the relationship direction is:
A. You avoid typo errors.  Was it -- or ->, look how close 1 and 2 are.
B. You know right away which direction you are going.  Compare 1 and 2, vs 4
and 5.  At the 6th character in both 4 and 5, you know which direction it
is.  You have to get to the 17th character in 1 and 2.
C. We read left to right so:
-- 1 reads: lucy via relationship acts_in outgoing to movie, 
-- 2 reads: lucy via relationship acts_in both to movie
-- 3 reads, lucy incoming via relationship acts_in to movie 
That is inconsistent.
Try:
-- 4 reads, lucy outgoing via relationshp acts_in to movie
-- 5 reads, lucy both via relationshp acts_in to movie
-- 6 reads, lucy incoming via relationshp acts_in to movie
D. try (a)-->(b)-->(c)-->(d)--(e)-->(f)-->(g)   #did you catch the both
relationship between d and e?  or did your eyes scan over it?  If you're
debugging someone else's code, was it a typo or did they intend it that way? 
If you spell it out there is no ambiguity.

Anyway, if the --> syntax is polarizing (as it seems to be) then *give
people the choice* to use whichever they prefer.

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481278.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Nigel Small]

Also agree. Using several illustrative symbols instead of one cryptic one
adds a considerable amount of readability as the expense of negligible
overhead. Since the "->" sequence is also used in C as a pointer operator,
it's nothing new.
*
*
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 4 November 2011 20:36, Tero Paananen  wrote:

> > I'd say the strongest part of Cypher is the "ascii art" pattern where you
> > clearly see what you're querying for, right there and then without having
> > to parse it into a graph into your head. Removing that would reduce my
> > interest in this language significantly.
>
> I strongly agree with this. It's EASY to see the relationships and
> their direction with the syntax right now.
>
> (cani)<-[:HAS]-(more)-[:CHEEZ]->(burger)
>
> I glance that and instantly figure out what it's trying to say. The SQL-
> like examples I've seen so far aren't coming even close, IMHO. And
> as the query complexity increases, I think the advantage Cypher's
> syntax has increases even more.
>
> Additionally I don't find adding a join keyword to a query language that
> queries a data store that has no joins better in any shape or form.
>
> -TPP
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Tero Paananen]

> I'd say the strongest part of Cypher is the "ascii art" pattern where you
> clearly see what you're querying for, right there and then without having
> to parse it into a graph into your head. Removing that would reduce my
> interest in this language significantly.

I strongly agree with this. It's EASY to see the relationships and
their direction with the syntax right now.

(cani)<-[:HAS]-(more)-[:CHEEZ]->(burger)

I glance that and instantly figure out what it's trying to say. The SQL-
like examples I've seen so far aren't coming even close, IMHO. And
as the query complexity increases, I think the advantage Cypher's
syntax has increases even more.

Additionally I don't find adding a join keyword to a query language that
queries a data store that has no joins better in any shape or form.

-TPP
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[maxdemarzi]

Can we make the ascii art more readable?

From:
lucy-[:ACTS_IN]->movie

What are some options:
lucy[:ACTS_IN]->movie # lose the second "-" by attaching the relationship to
a node
lucy[:ACTS_IN]movie  # instead of ---
lucy[:ACTS_IN]->movie #instead of --> 
lucy[:ACTS_IN]=>movie #instead of -->, using = instead of - 
lucy<-[:ACTS_IN]movie # instead of <--
lucy<=[:ACTS_IN]movie # instead of <--

lucy[:ACTS_IN]-movie  # just use one character
lucy[:ACTS_IN]=movie # instead of --> 

The existing syntax is not horrible, but can we do better?

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481174.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[KanTube]

At first glance i like the new syntax.  I am a bit confused on Andres comment
that PATTERN is a new construct and is not replacing WHERE.  But if you are
able to reproduce everything with this new syntax I am all for it.  and if
you are going to make this change - the sooner the better.  

not to suggest to many changes but i am not a fan of the "->", don't have
any suggestion to replace it but just not a fan of it.

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481110.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Mattias Persson]

2011/11/4 maxdemarzi 

> I think the reason we're even having this discussion is because the cypher
> syntax is close, but not quite SQL in the first place.  This makes the
> differences between the two languages stick out in my mind.
>
> I haven't had a lot of time on cypher, but as a newbie to the language I
> see
> a cypher query and I'm always thinking, RETURN = SELECT, START = FROM,
> PATTERN = JOIN.  So I'm doing the translation in my head back to SQL
> anyway.
>
> Let's just make it as SQLish as possible to get rid of that annoying
> internal translation.
>
> Cypher
> -=-=-=-=-
> START lucy = node(1000)
> MATCH lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> WHERE not(movie.title = "Water World")
> RETURN movie.title, count(*)
> ORDER BY count(*) DESC
>
> PQL
> -=-=-
> SELECT movie.title, count(*)
> FROM node(1000) as lucy
> JOIN lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> WHERE movie.title <> "Water World"
> ORDER BY count(*) DESC
>
> I like JOIN instead of MATCH.  Match is "The description of the pattern is
> made up of one or more paths, separated by commas." which closely resembles
> JOIN in SQL which is about describing the Relationships between tables...
> and once again I'm doing the translation in my head anyway, might as well
> eliminate that mental waste.
>
> Lastly, I'm not sure about the syntax for describing relationships.
>
> --> and <-- or --- with ?: makes me think chicken scratch not language.
> Using INCOMING, OUTGOING, OPTIONAL, AS, etc might make the query verbose,
> but maybe more readable?
>
>
I'd say the strongest part of Cypher is the "ascii art" pattern where you
clearly see what you're querying for, right there and then without having
to parse it into a graph into your head. Removing that would reduce my
interest in this language significantly.


> --
> View this message in context:
> http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481094.html
> Sent from the Neo4j Community Discussions mailing list archive at
> Nabble.com.
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[maxdemarzi]

I think the reason we're even having this discussion is because the cypher
syntax is close, but not quite SQL in the first place.  This makes the
differences between the two languages stick out in my mind.  

I haven't had a lot of time on cypher, but as a newbie to the language I see
a cypher query and I'm always thinking, RETURN = SELECT, START = FROM,
PATTERN = JOIN.  So I'm doing the translation in my head back to SQL anyway.

Let's just make it as SQLish as possible to get rid of that annoying
internal translation.

Cypher 
-=-=-=-=- 
START lucy = node(1000) 
MATCH lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor 
WHERE not(movie.title = "Water World")
RETURN movie.title, count(*) 
ORDER BY count(*) DESC 

PQL 
-=-=- 
SELECT movie.title, count(*) 
FROM node(1000) as lucy 
JOIN lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor 
WHERE movie.title <> "Water World"
ORDER BY count(*) DESC 

I like JOIN instead of MATCH.  Match is "The description of the pattern is
made up of one or more paths, separated by commas." which closely resembles
JOIN in SQL which is about describing the Relationships between tables...
and once again I'm doing the translation in my head anyway, might as well
eliminate that mental waste.

Lastly, I'm not sure about the syntax for describing relationships.  

--> and <-- or --- with ?: makes me think chicken scratch not language. 
Using INCOMING, OUTGOING, OPTIONAL, AS, etc might make the query verbose,
but maybe more readable?

--
View this message in context: 
http://neo4j-community-discussions.438527.n3.nabble.com/Neo4j-Cypher-Pickle-tp3480817p3481094.html
Sent from the Neo4j Community Discussions mailing list archive at Nabble.com.
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Peter Hunsberger]

Seems if you're trying to mimic SQL it would be a shame if the most common
construct was the least SQL like.  At an abstract semantic level (ie, not
digging into the code or real usage) PATTERN and WHERE seem close enough
that perhaps you can unify them?

In any case, I wouldn't say xPath is just tree structures, it can do
arbitrary grouping in addition to traversing up and down hierarchies. More
importantly, xQuery has to deal with graphs not trees since  you have
multiple ways of referencing related nodes (name and id in particular can
cause cycles or connections between branches).  Not sure it would map
directly to what you want, but I suspect you could build a syntax that was
more xQuery like than you will ever be able to build a syntax that
is truly SQL like?

Peter Hunsberger


On Fri, Nov 4, 2011 at 2:26 PM, Andres Taylor <
andres.tay...@neotechnology.com> wrote:

> On Fri, Nov 4, 2011 at 7:04 PM, Peter Hunsberger <
> peter.hunsber...@gmail.com
> > wrote:
>
> > One question,  and I bet I won't be the only one asking it...
> >
> > If SQL is the target to mimic, why not "WHERE" instead of "PATTERN"  ?
> >
>
> PATTERN is a new construct, not replacing WHERE. WHERE is still in
> there<
> https://github.com/neo4j/community/blob/pql/pql/src/test/scala/org/neo4j/pql/PqlParserTest.scala#L124
> >
> .
>
>
> > Otherwise, wouldn't xQuery be perhaps an even more logical target?
>
>
> Heathen!
>
> Seriously - it's mostly centered around XPath expressions, which are great
> for tree structures, but maybe not what we need for our complex patterns. I
> can't really see what's left of XQuery if you remove the XPath parts. Do
> you have any concrete ideas I could ponder over?
>
> Thanks a lot for your feedback - it makes our lives much easier when people
> are vocal about their opinions!
>
> Andrés
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Andres Taylor]

On Fri, Nov 4, 2011 at 7:04 PM, Peter Hunsberger  wrote:

> One question,  and I bet I won't be the only one asking it...
>
> If SQL is the target to mimic, why not "WHERE" instead of "PATTERN"  ?
>

PATTERN is a new construct, not replacing WHERE. WHERE is still in
there
.


> Otherwise, wouldn't xQuery be perhaps an even more logical target?


Heathen!

Seriously - it's mostly centered around XPath expressions, which are great
for tree structures, but maybe not what we need for our complex patterns. I
can't really see what's left of XQuery if you remove the XPath parts. Do
you have any concrete ideas I could ponder over?

Thanks a lot for your feedback - it makes our lives much easier when people
are vocal about their opinions!

Andrés
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Tero Paananen]

My take on this is to not use a SQL-like query language.

The reason is that while it looks like SQL it is not SQL, and the subtle
differences would be more confusing than with using a query language
that doesn't share SQL-like constructs.

-TPP
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Axel Morgner]

Hi,

like this, people familiar with SQL (which are many) don't have to 
think, they just read and understand.

+1

Axel

Am 04.11.2011 18:58, schrieb Peter Neubauer:
> Hi all,
> moving this discussion to the community, it is very important getting
> your feedback! Including Andres' original post on top again ...
>
> 2011/11/4 Andres Taylor
> Good afternoon, gentlemen.
>
> I've been involved in a sales thingie, and had to translate SQL to
> Cypher. At around the same time, Andreas suggested that we should call
> Cypher PQL (pickle) instead - Pattern Query Language.
>
> After sleeping on it, I realized the obviousness of the truth - if we
> want to hook Joe Corp Java-coder, having something that is similar to
> SQL is a Good Thing (TM). So this morning I changed Cypher (and the
> 228 breaking tests) to look like SQL.
>
> Example:
>
> Cypher
> -=-=-=-=-
> START lucy = node(1000)
> MATCH lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> RETURN movie.title, count(*)
> ORDER BY count(*) DESC
>
> PQL
> -=-=-
> SELECT movie.title, count(*)
> FROM node(1000) as lucy
> PATTERN lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> ORDER BY count(*) DESC
>
> The code is in place now (the branch is PQL). What's left to do is
> take care of cypher-plugin, check that I haven't missed anything in
> the manual, and make sure SDN doesn't mind. Michael assured me that
> that would not be a problem.
>
> The question is - should we make an effort to ship this with 1.5? I
> think we should. The change is purely syntactic - and that makes me
> feel comfortable that no new bugs have been introduced.
>
> Opinions?
>
> Andrés
>
> (Peter - happy now? You win!)
>
>
> On Fri, Nov 4, 2011 at 10:45 AM, David Montag
>   wrote:
> Sorta agree with Mattias. OTOH the syntax is pretty cool too. Could we
> ask the community? Could this discussion be had publicly? Also, I like
> the fact that Cypher flows forward and SQL flows backward.
>
> David
>
> 2011/11/4 Mattias Persson
> Going down the SQL-like path will certainly please many, but also
> anger others where it doesn't function exactly like SQL... that I
> don't think we'd get with that differentiated syntax. Also we'd have
> to put constraints on evolving the syntax with "no, we can't do that
> because that wouldn't be SQL like" and I'd really really dislike
> that; it'd make us followers instead of leaders.
>
> Den 4 november 2011 17:50 skrev Michael Hunger
> :
>
> I'll take it to be the devils advocate.
>
> Do we really want to be perceived as a "SQL-like" database (aka first
> association == RDBMS) also Pickle sounds like nitpicking and also like
> PL/SQL.
> What level of boringness do we want to afford.
>
> These are the gut feelings.
>
> What about all our users that already got comfortable with Cypher
> (which is a cooler name btw.) and are writing a lot of queries in it.
>
> Also our screencasts, documentation and third party libs (also
> provided by the community have to be updated, or at least checked and
> their docs updated).
>
> Putting select at the beginning breaks the flow somehow, the return at
> the end felt more natural, because I decided, what I want to project
> as one of the last things, LINQ did it better too.
>
> Are our node and relationship-sets in the start clause really like
> tables? (Aka sets of similar "rows") ? Probably
>
> Shoudn't we get rid then of the iconographic syntax as well? And
> default to something like
> FROM nodes() as x [LEFT OUTER|…] JOIN nodes() as y via r ON (r.type =
> 'KNOWS' and … )
>
> I know you're only taking on a role here, but I'd like to say: are you mad?
>
>
> etc.
>
> Having said that all,
>
> let's go for it.
>
> Michael
>
> Am 04.11.2011 um 17:14 schrieb Björn Granvik:
>
> I like it....a lot.
>
> Could someone be the devil's advocate and point to possible problems?
> Tech, ux, or whatever.
> Or is it truly just a good thing?
>
> /Björn
>
> 4 nov 2011 kl. 17:01 skrev Ian Robinson:
>
> I've got to say, that suddenly looks very good.
>
> Interesting moment at the NOSQL Exchange this week with someone
> struggling to 'see' the ASCII art representation of a graph : Cypher
> is perfectly comprehensible to me - it's only when you come across
> someone else's misunderstandings and difficulties that you see the
> benefits of conforming to expectations.
>
> I'd say: let's try get this into 1.5. The sooner we can start showing
> off something that devs already expect, the more we'll hook them, I'm
> sure.
>
> ian
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user


___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] Cypher->Pickle?

[Peter Hunsberger]

One question,  and I bet I won't be the only one asking it...

If SQL is the target to mimic, why not "WHERE" instead of "PATTERN"  ?

Otherwise, wouldn't xQuery be perhaps an even more logical target?

Peter Hunsberger


On Fri, Nov 4, 2011 at 12:58 PM, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:

> Hi all,
> moving this discussion to the community, it is very important getting
> your feedback! Including Andres' original post on top again ...
>
> 2011/11/4 Andres Taylor 
> Good afternoon, gentlemen.
>
> I've been involved in a sales thingie, and had to translate SQL to
> Cypher. At around the same time, Andreas suggested that we should call
> Cypher PQL (pickle) instead - Pattern Query Language.
>
> After sleeping on it, I realized the obviousness of the truth - if we
> want to hook Joe Corp Java-coder, having something that is similar to
> SQL is a Good Thing (TM). So this morning I changed Cypher (and the
> 228 breaking tests) to look like SQL.
>
> Example:
>
> Cypher
> -=-=-=-=-
> START lucy = node(1000)
> MATCH lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> RETURN movie.title, count(*)
> ORDER BY count(*) DESC
>
> PQL
> -=-=-
> SELECT movie.title, count(*)
> FROM node(1000) as lucy
> PATTERN lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
> ORDER BY count(*) DESC
>
> The code is in place now (the branch is PQL). What's left to do is
> take care of cypher-plugin, check that I haven't missed anything in
> the manual, and make sure SDN doesn't mind. Michael assured me that
> that would not be a problem.
>
> The question is - should we make an effort to ship this with 1.5? I
> think we should. The change is purely syntactic - and that makes me
> feel comfortable that no new bugs have been introduced.
>
> Opinions?
>
> Andrés
>
> (Peter - happy now? You win!)
>
>
> On Fri, Nov 4, 2011 at 10:45 AM, David Montag
>  wrote:
> Sorta agree with Mattias. OTOH the syntax is pretty cool too. Could we
> ask the community? Could this discussion be had publicly? Also, I like
> the fact that Cypher flows forward and SQL flows backward.
>
> David
>
> 2011/11/4 Mattias Persson 
> Going down the SQL-like path will certainly please many, but also
> anger others where it doesn't function exactly like SQL... that I
> don't think we'd get with that differentiated syntax. Also we'd have
> to put constraints on evolving the syntax with "no, we can't do that
> because that wouldn't be SQL like" and I'd really really dislike
> that; it'd make us followers instead of leaders.
>
> Den 4 november 2011 17:50 skrev Michael Hunger
> :
>
> I'll take it to be the devils advocate.
>
> Do we really want to be perceived as a "SQL-like" database (aka first
> association == RDBMS) also Pickle sounds like nitpicking and also like
> PL/SQL.
> What level of boringness do we want to afford.
>
> These are the gut feelings.
>
> What about all our users that already got comfortable with Cypher
> (which is a cooler name btw.) and are writing a lot of queries in it.
>
> Also our screencasts, documentation and third party libs (also
> provided by the community have to be updated, or at least checked and
> their docs updated).
>
> Putting select at the beginning breaks the flow somehow, the return at
> the end felt more natural, because I decided, what I want to project
> as one of the last things, LINQ did it better too.
>
> Are our node and relationship-sets in the start clause really like
> tables? (Aka sets of similar "rows") ? Probably
>
> Shoudn't we get rid then of the iconographic syntax as well? And
> default to something like
> FROM nodes() as x [LEFT OUTER|…] JOIN nodes() as y via r ON (r.type =
> 'KNOWS' and … )
>
> I know you're only taking on a role here, but I'd like to say: are you mad?
>
>
> etc.
>
> Having said that all,
>
> let's go for it.
>
> Michael
>
> Am 04.11.2011 um 17:14 schrieb Björn Granvik:
>
> I like it....a lot.
>
> Could someone be the devil's advocate and point to possible problems?
> Tech, ux, or whatever.
> Or is it truly just a good thing?
>
> /Björn
>
> 4 nov 2011 kl. 17:01 skrev Ian Robinson :
>
> I've got to say, that suddenly looks very good.
>
> Interesting moment at the NOSQL Exchange this week with someone
> struggling to 'see' the ASCII art representation of a graph : Cypher
> is perfectly comprehensible to me - it's only when you come across
> someone else's misunderstandings and difficulties that you see the
> benefits of conforming to expectations.
>
> I'd say: let's try get this into 1.5. The sooner we can start showing
> off something that devs already expect, the more we'll hook them, I'm
> sure.
>
> ian
> ___
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

[Neo4j] Cypher->Pickle?

[Peter Neubauer]

Hi all,
moving this discussion to the community, it is very important getting
your feedback! Including Andres' original post on top again ...

2011/11/4 Andres Taylor 
Good afternoon, gentlemen.

I've been involved in a sales thingie, and had to translate SQL to
Cypher. At around the same time, Andreas suggested that we should call
Cypher PQL (pickle) instead - Pattern Query Language.

After sleeping on it, I realized the obviousness of the truth - if we
want to hook Joe Corp Java-coder, having something that is similar to
SQL is a Good Thing (TM). So this morning I changed Cypher (and the
228 breaking tests) to look like SQL.

Example:

Cypher
-=-=-=-=-
START lucy = node(1000)
MATCH lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
RETURN movie.title, count(*)
ORDER BY count(*) DESC

PQL
-=-=-
SELECT movie.title, count(*)
FROM node(1000) as lucy
PATTERN lucy-[:ACTS_IN]->movie<-[:ACTS_IN]-co_actor
ORDER BY count(*) DESC

The code is in place now (the branch is PQL). What's left to do is
take care of cypher-plugin, check that I haven't missed anything in
the manual, and make sure SDN doesn't mind. Michael assured me that
that would not be a problem.

The question is - should we make an effort to ship this with 1.5? I
think we should. The change is purely syntactic - and that makes me
feel comfortable that no new bugs have been introduced.

Opinions?

Andrés

(Peter - happy now? You win!)


On Fri, Nov 4, 2011 at 10:45 AM, David Montag
 wrote:
Sorta agree with Mattias. OTOH the syntax is pretty cool too. Could we
ask the community? Could this discussion be had publicly? Also, I like
the fact that Cypher flows forward and SQL flows backward.

David

2011/11/4 Mattias Persson 
Going down the SQL-like path will certainly please many, but also
anger others where it doesn't function exactly like SQL... that I
don't think we'd get with that differentiated syntax. Also we'd have
to put constraints on evolving the syntax with "no, we can't do that
because that wouldn't be SQL like" and I'd really really dislike
that; it'd make us followers instead of leaders.

Den 4 november 2011 17:50 skrev Michael Hunger
:

I'll take it to be the devils advocate.

Do we really want to be perceived as a "SQL-like" database (aka first
association == RDBMS) also Pickle sounds like nitpicking and also like
PL/SQL.
What level of boringness do we want to afford.

These are the gut feelings.

What about all our users that already got comfortable with Cypher
(which is a cooler name btw.) and are writing a lot of queries in it.

Also our screencasts, documentation and third party libs (also
provided by the community have to be updated, or at least checked and
their docs updated).

Putting select at the beginning breaks the flow somehow, the return at
the end felt more natural, because I decided, what I want to project
as one of the last things, LINQ did it better too.

Are our node and relationship-sets in the start clause really like
tables? (Aka sets of similar "rows") ? Probably

Shoudn't we get rid then of the iconographic syntax as well? And
default to something like
FROM nodes() as x [LEFT OUTER|…] JOIN nodes() as y via r ON (r.type =
'KNOWS' and … )

I know you're only taking on a role here, but I'd like to say: are you mad?


etc.

Having said that all,

let's go for it.

Michael

Am 04.11.2011 um 17:14 schrieb Björn Granvik:

I like it....a lot.

Could someone be the devil's advocate and point to possible problems?
Tech, ux, or whatever.
Or is it truly just a good thing?

/Björn

4 nov 2011 kl. 17:01 skrev Ian Robinson :

I've got to say, that suddenly looks very good.

Interesting moment at the NOSQL Exchange this week with someone
struggling to 'see' the ASCII art representation of a graph : Cypher
is perfectly comprehensible to me - it's only when you come across
someone else's misunderstandings and difficulties that you see the
benefits of conforming to expectations.

I'd say: let's try get this into 1.5. The sooner we can start showing
off something that devs already expect, the more we'll hook them, I'm
sure.

ian
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user