You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Sridhar Ramachandran <la...@gmail.com> on 2016/02/02 23:04:20 UTC
Few questions on TP3
Hi all,
I am trying to port Bitsy graph DB from TP2 to TP3. I have a few questions
on TP3:
1. Is this mailing list searchable? I don't want to ask questions that have
already been answered.
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.
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.
3. What happened to KeyIndexableGraph? We used to rely on this interface to
find vertices by a natural key besides the UUID.
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?
If tx1 and tx2 are the same object, tx1.isOpen() will return true even
though the transaction has been closed.
(b) If tx1 or tx2 is accessed by a different thread, what is the accepted
behavior?
(c) I read somewhere (can't find it anymore) that transactions can be
automatically opened when operations are performed. If so, how does the
user know if the transaction is open or not? In other words, g.tx() will
have to return the same object in the same thread for the user to be able
to detect that a transaction is underway, if automatic open/close of
transactions is allowed.
Regards,
Sridhar.
Re: Few questions on TP3
Posted by Sridhar Ramachandran <la...@gmail.com>.
Thanks guys!
On 2/3/2016 8:44 AM, Marko Rodriguez wrote:
> 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 <sp...@gmail.com> 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/list.html?dev@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.
>>
>
Re: Few questions on TP3
Posted by Marko Rodriguez <ok...@gmail.com>.
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 <sp...@gmail.com> 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/list.html?dev@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.
>
>>
Re: Few questions on TP3
Posted by Stephen Mallette <sp...@gmail.com>.
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?dev@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.
>