Great to hear that it works Tom, looks good! Have you put index in place
and are you doing parametered queries in order for better performance as
well ? (or mabey it works good "as is" ?). For the typecasting, well
yes..but i guess some kind of type assertion needs to be in place on the
server anyhow but souldnt be needed for the end-user to explicit do the
typecasting so i guess i agree with that. Hopefully someone from the Neo4j
team can chime in.
Den lördagen den 19:e april 2014 kl. 12:52:33 UTC+2 skrev Tom Zeppenfeldt:
>
> Hi Lundin,
>
> Thanks a lot for your replies and efforts to find a workaround. I finally
> decided to use the explicit typecasting, and build the rest of the cypher
> statement which now looks as this:
>
> MATCH (p:project {name:
> "ProjA"})-[:CURRENT|PREV*]->(pv:projversion)-[pu:ADD|REMOVE]->(pt:projtransition)<-[:HASALIAS]-(tt:transition)
>
> WHERE pv.version <= 1
> WITH tt,pv,type(pu) AS putype ORDER BY tt.id,pv.version DESC
> WITH tt,HEAD(collect(putype)) AS lastputype WHERE lastputype = "ADD"
> MATCH (tt)<-[tu:ADD|REMOVE]-(tv:tocversion)
> WITH tt,tu,tv ORDER BY tt.id,tv.version DESC
> WITH tt,COLLECT([type(tu),tv.version]) AS tus
> WITH tt, HEAD([x IN tus WHERE str(x[1])<=str(4) | [x[0],x[1]]]) AS
> lastupdate WHERE lastupdate[0] <> "ADD"
> RETURN tt.id as conflicting
>
> Which returns nodes that are conflicting (i.e. were not yet created or
> were already deleted) in specific versions of two different networks.
> Do you agree with me that this typecasting should not be necessary and
> that cypher internally does some weird things that prevents comparing of
> integer values ?
>
>
--
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/d/optout.
