> I was wondering if there was anyway via the REST API to run multiple Cypher queries in a single transaction. I haven't be able to find anything on multiple statements Cypher queries nor anyway to manage transactions via the REST API.

> I do have an idea of how something like this could work though.
> For each request there's a single transaction in play.
> Cypher queries are streamed in the form of a JSON objects. As results become available they are streamed back to the client.
> If the client wants to run multiple Cypher queries it simply streams multiple JSON objects (not necessarily in the form of an array is the upper bound is unknown).
> If the client wants to abort the transaction it sends a "TRANSACTION ABORT" Cypher query (this would be an extension to the Cypher query language).
> Otherwise, when the connection is closed the transaction is committed. Ideally, all the data/status information should have arrived at the client so the transaction should commit fine, if this is a problem then a similar "TRANSACTION COMMIT" might be useful.
> The point is that it creates a comet programming like way for any client via the REST API to stream Cypher queries work on the results and then maybe stream some more, all within the same transaction.

> I'm unsure as to what the cost is for having significantly longer transactions in play, as well as keeping additional HTTP sockets occupied but I do believe that something like this is useful to fully leverage transactions via Cypher and the REST API and more efficient than issuing multiple HTTP requests for creating, running and committing mutating queries.

> I'm I completely mad suggesting something like this?

On Thursday, August 2, 2012 10:55:36 AM UTC+2, Michael Hunger wrote:

> Something like this is planned in the future but outside the scope of
> cypher probably.

> Right now you can use the REST batch operations to send multiple cypher
> queries in a single transaction/request.

> With the header X-Stream:true both inputs and outputs will be streamed.

> With an invalid cypher query (like 'ABORT') you can cause an exception to
> be thrown which will roll back the server. (Kind of a poison pill)

> HTH

> Michael

> Am 01.08.2012 um 22:14 schrieb John Leidegren:

> I was wondering if there was anyway via the REST API to run multiple
> Cypher queries in a single transaction. I haven't be able to find anything
> on multiple statements Cypher queries nor anyway to manage transactions via
> the REST API.

> I do have an idea of how something like this could work though.

>    - For each request there's a single transaction in play.
>    - Cypher queries are streamed in the form of a JSON objects. As
>    results become available they are streamed back to the client.
>    - If the client wants to run multiple Cypher queries it simply streams
>    multiple JSON objects (not necessarily in the form of an array is the upper
>    bound is unknown).
>    - If the client wants to abort the transaction it sends a "TRANSACTION
>    ABORT" Cypher query (this would be an extension to the Cypher
>    query language).
>    - Otherwise, when the connection is closed the transaction
>    is committed. Ideally, all the data/status information should have arrived
>    at the client so the transaction should commit fine, if this is a problem
>    then a similar "TRANSACTION COMMIT" might be useful.

> The point is that it creates a comet programming like way for any client
> via the REST API to stream Cypher queries work on the results and then
> maybe stream some more, all within the same transaction.

> I'm unsure as to what the cost is for having significantly longer
> transactions in play, as well as keeping additional HTTP sockets occupied
> but I do believe that something like this is useful to fully leverage
> transactions via Cypher and the REST API and more efficient than issuing
> multiple HTTP requests for creating, running and committing mutating
> queries.

> I'm I completely mad suggesting something like this?

> Is there a Batch Operation example with Cypher? I want to group multiple Cypher Queries as a transaction.

> Thanks

> --