Repository: thinkaurelius/titan

Issue #476: Bug in Titan BerkeleyDB
Created: 2013-11-11T17:46:22Z
Graph configuration:
storage.backend=berkeleyje
storage.directory=$path/standard
storage.index.lucene.backend=lucene
storage.index.lucene.directory=$path/lucene
storage.buffer-size=2048
ids.block-size=500000

g.makeKey(UI).dataType(classOf[String]).indexed(classOf[Vertex]).unique(UniquenessConsistency.LOCK).make()
g.makeKey(TYPE).dataType(classOf[String]).indexed(classOf[Vertex]).indexed("lucene",classOf[Vertex]).make()
g.makeKey(TEXT).dataType(classOf[String]).indexed("lucene",classOf[Vertex]).make()
g.makeKey(SOURCE).dataType(classOf[String]).indexed(classOf[Edge]).make()
g.makeKey(WEIGHT).dataType(classOf[java.lang.Double]).indexed(classOf[Edge]).make()
g.commit()

final val UI = "ui"
final val TYPE = "type"
final val TEXT = "text"
final val SOURCE = "source"
final val WEIGHT = "weight"

//open/create graph
graph = TitanFactory.open(titanConf)

I filled the graph with my data and tested the following with gremlin:
gremlin> g.v(252).ui
==>C0033684
gremlin> g.v(724).ui
==>C0033684
gremlin> g.v(1016).ui
==>C0033684
gremlin> g.v(7644).ui
==>C0033684

This should not be possible after the given type declaration, that 'ui' should be unique. During indexing, I query the graph for a given vertex with the given 'ui'. If it exists, I take it and add an edge to it. If not I create it first.
This is how I query the graph for the vertex:
val it1 = graph.query.has('ui', Compare.EQUAL, c1.conceptId).limit(1).vertices()

How can it happen that there are many vertices with the same ui?

Duplicate issue #471: Bug RexsterClient traversal
Created: 2013-11-08T16:17:47Z
I am querying the graph through rexpro with many queries (only reading, no writing) and mysteriously at some point the results of one query change (becoming wrong results). I try to verify the problem in gremlin and I cannot reproduce the problem. I know which queries were issued prior to the problem:
g.v(2152).transform{[ it.outE('hmod -> induce:VB -> pobj').count(), it.depth, it.totalDepth ]}.next()                                                                        --> gives right result
g.v(35416).inE.filter{!notAllowed.contains(it.label)}.transform{[it.label,it.outV.next().ui,it.outV.next().text]}
g.v(35416).outE.filter{!notAllowed.contains(it.label)}.transform{[it.label,it.inV.next().ui,it.inV.next().text]}
g.v(2152).transform{[ it.outE('hmod -> induce:VB -> pobj').count(), it.depth, it.totalDepth ]}.next()                                                                        --> gives wrong result     

If I issue those queries before I run my loop (in which I do some traversing), it works. Inside the loop, after some traversing it doesn't anymore.
I cannot figure out what the problem is, but it is very weird and seems to only happen to edges with this label.

Closing comment (2013-11-12T09:23:24Z): That is the same problem I had. I tried to reproduce the problem by finding out which queries were being issued prior to that problem and applying those to the graph where the change happened. Unfortunately this did not reproduce the error and I am kind of stuck. However, I will try to figure out a way to see what's really going on. It might be related to some elusive graph inconsistencies I reported in #476.