Hey Sridhar - nice to see you on the list. I am trying to port Bitsy graph DB from TP2 to TP3. I have a few questions > on TP3: >
sweet - if you haven't read this section of the docs yet, you probably should give it a review: http://tinkerpop.apache.org/docs/3.1.0-incubating/#implementations > 1. Is this mailing list searchable? I don't want to ask questions that have > already been answered. > your best shot of searching is here - https://pony-poc.apache.org/list.html?d...@tinkerpop.apache.org > 2. Is there any implementation that was ported from TP2 to TP3? I see many > total rewrites, but I'm looking to see diffs across classes. > They are basically re-writes - as the API is fairly different. I'd say Titan was the most resilient to the API implementation. There was lots of renaming and moving things about, but no one re-wrote Titan from scratch. > 2b. Is there any example of an app that was ported from TP2 to TP3? If this > process is hard, I'm thinking of launching the TP3 port as a separate > project. > No examples that I know of. Note that TinkerPop3 launched as a new and separate project. That might be easiest, but I'm not sure how bitsy is setup from an abstraction perspective. With the right abstractions maybe you're process for Bitsy is a lot like Titan's as compared to what we did for Neo4j or TinkerGraph. > 3. What happened to KeyIndexableGraph? We used to rely on this interface to > find vertices by a natural key besides the UUID. > TinkerPop no longer has abstractions over indices (nor does it have that convoluted inheritance hierarchy over the Graph interface). Users must drop down to the indexing API of the provider implementation to create indices. Bitsy would then develop a TraversalStrategy to optimize queries using those indices behind the scenes. http://tinkerpop.apache.org/docs/3.1.0-incubating/#traversalstrategy and here's the implementation from Neo4j https://github.com/apache/incubator-tinkerpop/blob/ffbecdb870e5d4a840b0445447d96c27c3d84e3a/neo4j-gremlin/src/main/java/org/apache/tinkerpop/gremlin/neo4j/process/traversal/strategy/optimization/Neo4jGraphStepStrategy.java and TinkerGraph: https://github.com/apache/incubator-tinkerpop/blob/ffbecdb870e5d4a840b0445447d96c27c3d84e3a/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/process/traversal/strategy/optimization/TinkerGraphStepStrategy.java 4. Should the tx() method always return the same object within the same > thread, or a different object for each transaction? For instance: > Transaction tx1 = g.tx(); > tx1.open(); > // .. do some stuff > tx1.close(); > assert tx1.isOpen() == false; > Transaction tx2 = g.tx(); > tx2.open(); > > At this point, if tx1 and tx2 are different objects, tx1.open() will > launch two parallel transactions in the same thread. This means that two > transactions can happen on the same thread. Is that allowed? > The tx() method should return the same object - no need to create a fresh on each time. It is basically just a means to organize the transactional methods and not meant to be some handle to a "transaction object". Standard transactions are still like TinkerPop 2.x - they are bound to a thread. You can also choose to support a transactions that are not bound to threads via Transaction.createThreadedTx() which returns a Graph that is not bound to the current thread. Multiple threads can act on the same transaction. We had these in TinkerPop 2.x as well available via the ThreadedTransactionalGraph interface. >
