Things that I don't know if are even possible in Cypher

[Javier de la Rosa]

But I would like to see sometime in the future. I don't know if what
I'm going to say is just madness or senseless, but I talk inspired by
the new mutating features in Cypher.

First of all, returns all the properties of a node or relationship in
a tabular way. Something like

START n=node(1,2,3) return n.*

Or if "*" could be a property key, use instead

START n=node(1,2,3) return PROPS(n)

Second one is about indexing operations.

INDEX CREATE "my index" FOR node WITH {fulltext: TRUE}

INDEX DELETE "my index"

Indexing a new node

CREATE n={name: "Roger"} INDEX n ON node:`my index`["name"][n.name]

Indexing after a query

START n=node(1,2,3) INDEX n ON node:`my index`["name"][n.name] RETURN n

Unindexing

START n=node:`my index`("name:*") INDEX n OUT node:`my
index`["name"][n.name]

Multiple queries (specially usefull in REST)

CREATE n={name: "Roger"};
CREATE m={name: "Don"};
n-[r:WORKS_WITH]->m RETURN r;

Sub-querying (I think this could be done using the proper combination
of WHERE's and MATCH's)

START m=node(*) MATCH m-[r:WORK_WITH]->l WHERE l IN (START
n=node:`my index`("name:*") RETURN n) RETURN r

Transactions

BEGIN;
CREATE n={name: "Roger"};
CREATE m={name: "Don"};
n-[r:WORKS_WITH]->m RETURN r;
COMMIT;

And finally some way to make operations with Dates.

That's it. If I said something valuable, keep it. If I don't, just
ignore the e-mail :-)
Cheers!


--
Javier de la Rosa
http://versae.es

[Andres Taylor]

Thanks so much for this email! Answers inline.

On Thu, Apr 26, 2012 at 3:37 AM, Javier de la Rosa <ver...@gmail.com> wrote:

But I would like to see sometime in the future. I don't know if what
I'm going to say is just madness or senseless, but I talk inspired by
the new mutating features in Cypher.

First of all, returns all the properties of a node or relationship in
a tabular way. Something like

   START n=node(1,2,3) return n.*

Or if "*" could be a property key, use instead

   START n=node(1,2,3) return PROPS(n)

This has been asked for over and over again. Peter Neubauer asked for it yesterday. The problem I have with it, is that the result table will be irregularly shaped, and that bothers me a little. Since so many ask for it, we'll just have to figure out a way to make it work nicely.

 

Second one is about indexing operations.

I'll fight this until my death. (Dramatic, heh?)

Let me explain myself. Indexes are redundant data, used to speed up queries. Redundant data is bad, and something the user of a database shouldn't have to remember taking care of manually. So explicit index operations like you described are not very good - if you enter new data, and forget to index your nodes and relationships, your results will be surprising and probably wrong.

So, I think we need much stronger indexing support than we have today. We need some schema that tells the database how you want your data indexed - and does the indexing for you. Providing manual index operations would be to re-enforce something that I think is broken.

 

Multiple queries (specially usefull in REST)

   CREATE n={name: "Roger"};
   CREATE m={name: "Don"};
   n-[r:WORKS_WITH]->m RETURN r;

This very query is already possible:   

CREATE 

    n={name: "Roger"}, 

    m={name: "Don"},

    n-[r:WORKS_WITH]->m 

RETURN r;

In general - I agree. Multiple queries would be nice, especially considering explicit transactions like below.

Sub-querying (I think this could be done using the proper combination
of WHERE's and MATCH's)

   START m=node(*) MATCH m-[r:WORK_WITH]->l WHERE l IN (START
n=node:`my index`("name:*") RETURN n) RETURN r

Also something I see in our future. The exact look of it is still up in the air, but sub queries make a lot of sense.

 

Transactions

   BEGIN;
   CREATE n={name: "Roger"};
   CREATE m={name: "Don"};
   n-[r:WORKS_WITH]->m RETURN r;
   COMMIT;

Yes. Oh yes. There's some infrastructure that needs to be built, but I agree 100%.

 

And finally some way to make operations with Dates.

Again - I agree. Although, I want support for dates to be in a lower level - Cypher should not have to translate data types, the kernel should handle that for us.

Thanks for sharing your thinking Javier. Appreciate it.

Andrés

[Javier de la Rosa]

On Thu, Apr 26, 2012 at 02:18, Andres Taylor
<andres...@neotechnology.com> wrote:
> Thanks so much for this email! Answers inline.

You are welcome :-D

> This has been asked for over and over again. Peter Neubauer asked for it
> yesterday. The problem I have with it, is that the result table will be
> irregularly shaped, and that bothers me a little. Since so many ask for it,
> we'll just have to figure out a way to make it work nicely.

Nice!

> I'll fight this until my death. (Dramatic, heh?)

I see. And it makes all the sense for me too. I don't like having to
use manual indexing, but since I've been using it for a long time ago,
I don't see how to stop now. Maybe adding a new property in the nodes?
I describe birefly my use case. I have a platform [1] in which users can
create their own graphs and for them they describe schemas, but I
mantain schemas out of Neo4j. Then they are able to enter nodes and
relationships according the schemass previously created. Finally, the
only way I was able to have separate graphs inside the same Neo4j
instance was using manual indices.

> This very query is already possible:

Nice indeed! Are there also options to UPDATE and DELETE?

> Yes. Oh yes. There's some infrastructure that needs to be built, but I agree
> 100%.

Or even more complex with stamements like SAVEPOINT and ROLLBACK.

> Again - I agree. Although, I want support for dates to be in a lower level -
> Cypher should not have to translate data types, the kernel should handle
> that for us.

Good!

> Thanks for sharing your thinking Javier. Appreciate it.

Thank you for your quick response. I like Cypher a lot and I think it
could be the definitive access point to Neo4j, both for embedded and
REST. And then, we can create native bindings for languages like
Python and just choose what kind of connection do you want to use.

Best regards.



[1] Sylva: http://sylvadb.com/

[Nigel Small]

On 26 April 2012 07:18, Andres Taylor <andres...@neotechnology.com> wrote:

Thanks so much for this email! Answers inline.

On Thu, Apr 26, 2012 at 3:37 AM, Javier de la Rosa <ver...@gmail.com> wrote:

But I would like to see sometime in the future. I don't know if what
I'm going to say is just madness or senseless, but I talk inspired by
the new mutating features in Cypher.

First of all, returns all the properties of a node or relationship in
a tabular way. Something like

   START n=node(1,2,3) return n.*

Or if "*" could be a property key, use instead

   START n=node(1,2,3) return PROPS(n)

This has been asked for over and over again. Peter Neubauer asked for it yesterday. The problem I have with it, is that the result table will be irregularly shaped, and that bothers me a little. Since so many ask for it, we'll just have to figure out a way to make it work nicely.

Passing thought: could this be done with a "map" return type? Something along the lines of:

START n=node(1,2,3) return n, map(n.*)
+---------+-------------------+
| n       | map(n.*)          |
+---------+-------------------+
| Node(1) | {"foo":"bar"}     |
| Node(2) | {"name":"Fred"}   |
| Node(3) | {"one":1,"two":2} |
+---------+-------------------+

Nige