Hi,
To add on to Stephen's email. If you tell me what sort of optimizations Bitsy,
I can help you write respective TraversalStrategies. For instance, index
lookup, vertex-centric indices, embarrassingly parallel execution, etc.
Here are a few links about TraversalStrategies.
http://tinkerpop.apache.org/docs/3.1.1-SNAPSHOT/reference/#traversalstrategy
http://tinkerpop.apache.org/docs/3.1.1-SNAPSHOT/reference/#explain-step
https://github.com/apache/incubator-tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerGraph.java#L73-L75
HTH,
Marko.
http://markorodriguez.com
On Feb 3, 2016, at 4:53 AM, Stephen Mallette <[email protected]> wrote:
> 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/[email protected]
>
>
>> 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.
>
>>
