> Am 31.03.2015 um 23:14 schrieb Josef Karthauser <[email protected]>: > > 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.
That would be great, thanks so much ! Michael > > 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 <joe.kar...@ >> <>wansdyketele. <http://wansdyketele.com/>com <http://wansdyketele.com/>>: >> >> On 31 Mar 2015, at 08:33, Dr Josef Karthauser <joe.kar...@ <>wansdyketele. >> <http://wansdyketele.com/>com <http://wansdyketele.com/>> 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 <http://n.id/>) >> with n as referencing >> match q<-[*]-(m) where id(q) = referencing.id <http://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 neo4j+un...@ <>googlegroups.com <http://googlegroups.com/>. >> For more options, visit https://groups.google.com/d/optout >> <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
