It is strange isn't it. I am using an embedded database. I removed all the bad spatial linkages, and then checked to see that all of my domain objects were otherwise indexed correctly, and they were. So we have to explain how these self referencing nodes happened.
The only story that makes sense to me, and granted I don't know how the transaction code works so it might be impossible, is that the domain objects got rolled back when the database crashed, but the spatial index nodes didn't. I can try again with a fresh database and see whether it's reproducible easily enough. I'll try and do that tomorrow and report back. Cheers, Joe On Tuesday, March 31, 2015 at 2:13:59 PM UTC+1, Michael Hunger wrote: > > The index links to the domain nodes via the id-property. > > This is weird as both should happen in the same transaction at least in > embedded. > > Do you think you can reproduce that issue? > > Michael > > Am 31.03.2015 um 12:16 schrieb Dr Josef Karthauser < > [email protected] <javascript:>>: > > On 31 Mar 2015, at 08:33, Dr Josef Karthauser <[email protected] > <javascript:>> wrote: > > > [cut] > > I can only assume that something like the following happened. In the lead > up to an ‘out of file handles crash’ a spatially indexed node was added to > the database with id 874121, and then added to the spatial index. During > the crash, restart, transaction unwind node 874121 was wound back, but the > spatial node referencing it was not. Then, during the next run a new node > with id 874121 was created, but this was an index node, not a data node. > > That sounds crazy, but plausible. But, if true suggests then the > transaction protection isn’t absolute. Running out of file handles is a > likely outcome and transactions should protect against corruption in this > scenario, right? Why isn’t the spatial index also getting wound back after > a transaction failure? > > This is with neo4j-2.1.6 and neo4j-spatial 0.13 > > > This is the extent of the problem: > > match (:ReferenceNode)--(m {layer: "topography"}) > match m-[*]->(n) where has(n.id) > with n as referencing > match q<-[*]-(m) where id(q) = referencing.id > return count(q) > > > count(q)114 > Returned 1 row in 1285 ms > That looks like 114 cross links within the index to me. > > Is my interpretation right? I’m minded to just delete all of these > ‘referencing’ nodes, and hopefully that will fix the index. > > Joe > > -- > 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] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
