Yep, that's what it does in the non-streaming case.

afaik case 3 and 4 return a http 500

in streaming you don't know b/c you send the headers before each of the queries 
is actually processed and their results come in even later than that, so no way 
of updating http headers. that's why the streaming approach adds error messages 
to the payload.

e.g. see 
http://docs.neo4j.org/chunked/stable/rest-api-transactional.html#rest-api-handling-errors

HTH

Michael

Am 01.02.2014 um 16:23 schrieb brian <[email protected]>:

> Hi Michael,
> 
> I can't give you the code, but I can probably work up a test case.  Although 
> it's actually pretty simple.  Just create two nodes with a relationship 
> between them.  Then issue a Cypher query that would find one of the nodes (it 
> could just be a simple query on some property of one of the nodes) and delete 
> that node.  So something like
> 
> START n = node(*) WHERE n.myprop = something DELETE n
> 
> As to what error I'm expecting...  I would expect an error in the HTTP status 
> code.  But I understand that there's some controversy around this since the 
> resource I'm addressing via the /cypher endpoint is the query itself and the 
> query was valid.  This is part of the problem in issuing queries in a RESTful 
> API.  Anyway, could you tell me what I should expect?  I think there are 3 
> cases:
> 
> - The query was valid and the delete was successful and one or more entities 
> were deleted.  I would expect to get an HTTP 200. Not sure what I should see 
> in the payload although some indication of which entities or how many 
> entities were deleted would be helpful.
> - The query was valid and the delete was successful, but no entities were 
> deleted because the predicate didn't match any entities.  I would expect an 
> HTTP 200 here.
> - The query was valid and the delete was NOT successful due to an error (such 
> as the constraint violation I described). What is the expected behavior here?
> - The query was invalid.  I'd expect at least an error in the HTTP status 
> (probably a 400) and maybe some more details in the payload.
> 
> Thanks.
> 
> -brian
> 
> 
> On Friday, January 31, 2014 8:46:05 PM UTC-5, Michael Hunger wrote:
> Do you have the example code & REST call?
> 
> What kind of error are you referring to? http status code or payload ?
> 
> Michael
> 
> Am 31.01.2014 um 22:50 schrieb brian <[email protected]>:
> 
>> Hi all,
>> 
>> I've constructed a query that will result in a DELETE on a Node with 
>> existing relationships. When executed in the Neo4j browser, this returns an 
>> Exception as expected.  And I can see a stack trace in console.log that ends 
>> with a ConstraintViolationException (also as expected).  When I execute this 
>> same query via the REST API using the /cypher endpoint I still see the 
>> exception in console.log, but no error is returned by the REST API.  I'm 
>> pretty sure this is a change in behavior as I now have a unit test that is 
>> failing against Neo4j 2.0, but is not failing against Neo4j 1.8.x/1.9.x.
>> 
>> I'd be happy to create an issue on this, but wanted to get some feedback 
>> first.
>> 
>> -brian
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Neo4j" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to