[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map but puts non String keys in it!
[
https://issues.apache.org/jira/browse/TINKERPOP-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696904#comment-15696904
]
ASF GitHub Bot commented on TINKERPOP-1483:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/446
> Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`?
By `map.get(T.id)`. Providers may allow property names that match
TinkerPop's token accessors, hence `map.get(T.id)` must not be the same as
`map.get("id")` / `map.get(T.id.getAccessor())` and a user-defined `id`
property may not overwrite and may not be overwritten by the internal element
id.
> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in
> Java fails. toString() are missing... But do we rely on having these keys in
> other operations?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/446
> Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`?
By `map.get(T.id)`. Providers may allow property names that match
TinkerPop's token accessors, hence `map.get(T.id)` must not be the same as
`map.get("id")` / `map.get(T.id.getAccessor())` and a user-defined `id`
property may not overwrite and may not be overwritten by the internal element
id.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (TINKERPOP-1564) Distributed OLTP Traversals and the Introduction of Partition Concept
[
https://issues.apache.org/jira/browse/TINKERPOP-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15696414#comment-15696414
]
pieter martin commented on TINKERPOP-1564:
--
Ok,
I have never used TinkerPop's as OLAP, are there any OLAP implementation at
present that supports transactions?
If we talk about a transaction do we mean ACID or some weaker, eg. eventually
consistent, form of it?
The only truly distributed ACID system I know of is
[cockroachdb|https://github.com/cockroachdb/cockroach]. Its very interesting
and complex (raft consensus and all that). However its not where TinkerPop is
at, being a layer above the actual transaction/db semantics.
If GremlinServer is going to become a transaction manager managing the
transaction boundary across many remote data sources then it is very close to
the JTA 2 phase XA specification. I remember reading long ago that Neo4j
supports it. Neo4j's transaction implementation is a "proper" JTA specification
implementation if I recall correctly.
Next confusion is, for OLTP across threads, not machines, a similar transaction
manager will have to be present in or near gremlin-core?
> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the
> need for OLAP {{GraphComputer}} by introducing distributed, data local
> processing to OLTP. In essence, this is a proposal for a step-by-step query
> routing framework within {{Traversal}}. This proposal can work across
> machines in a cluster, threads on a machine, or in a hierarchical fashion
> machines&threads. The example presented will discuss distribution across
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and
> pulls vertex/edge/etc. data to it accordingly in order to solve the
> traversal. In OLAP, the traversal is cloned and distributed to all machines
> in the cluster and traversals communicate with one another by sending
> {{Traversers}} (i.e. messages) between themselves ensuring data local
> processing. Given recent advancements in GremlinServer and
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the
> {{Traverser}} is no longer accessing data local to the current machine. In
> order to do data local query routing, every adjacency would feed into a
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}}
> distribution) across the cluster where "sibling" {{PartitionSteps}} would
> have network access to one another using the same protocol of
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4
> node cluster example, the above traversal would be overlaid as below. Note
> that {{partition()}} would not be a new step in the language, but simply
> provided here to show where {{PartitionStrategy}} would insert
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>^
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three
> "worker traversals." Note that this is identical to current Gremlin OLAP.
> Now, the master traversal would be the traversal that is {{.next()}}'d for
> results. So, when the "master traversal" is {{next()}}'d, {{g.V(1)}} will
> fetch {{v[1]}} and then its outgoing knows-adjacencies. These adjacent
> "reference vertices" would be fed into the first {{remote()}} and a "routing
> algorit
[jira] [Commented] (TINKERPOP-1566) Kerberos authentication for gremlin-server
[ https://issues.apache.org/jira/browse/TINKERPOP-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695818#comment-15695818 ] Marc de Lignie commented on TINKERPOP-1566: --- A first test demonstrating Kerberos authentication between gremlin-driver and gremlin-server is available at: https://github.com/vtslab/incubator-tinkerpop/tree/TINKERPOP-1566/gremlin-server Relevant tests are: SaslAppTest (a copied smoketest for the kdc text fixture) AuthKrb5IntegrateTest (which tests the new Krb5Authenticator class) Still lots of work to do regarding configuration, clean-up, additional tests and documentation. > Kerberos authentication for gremlin-server > -- > > Key: TINKERPOP-1566 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1566 > Project: TinkerPop > Issue Type: Improvement > Components: server >Reporter: Marc de Lignie >Priority: Minor > Labels: security > Fix For: 3.3.0 > > > Gremlin server would benefit from an explicit Kerberos authentication plugin, > because preparing and maintaining such a plugin is nontrivial. Also, many > other Apache project provide kerberized services. > In gremlin-console the standard Krb5LoginModule can be configured. > Gremlin-server already includes the pluggable Sasl framework that can host > the proposed Kerberos authentication plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1564) Distributed OLTP Traversals and the Introduction of Partition Concept
[
https://issues.apache.org/jira/browse/TINKERPOP-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695760#comment-15695760
]
stephen mallette commented on TINKERPOP-1564:
-
I was reading about 2 phase commits a little bit yesterday - ugh - hurty. I
think we need the strategy for transactions reasonably planned out before we go
too deep into implementation. I don't think it's good to say "it works but it's
for read-only traversals only" so i'd prefer to avoid the situation of throwing
exceptions on partitioned traversals that have mutating steps. I suppose those
could be routed in such a way that they would just work like a regular
traversal so as to avoid the exception, but I think it's worth thinking big
here for what I think would be a 3.3.0 feature. I mean we're already have
problems with transactional boundaries on "remote" traversals. Perhaps that
issues needs to be addressed as part of thinking on this.
> Distributed OLTP Traversals and the Introduction of Partition Concept
> -
>
> Key: TINKERPOP-1564
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1564
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, process, server
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>
> This proposal unifies OLTP and OLAP into a single framework that removes the
> need for OLAP {{GraphComputer}} by introducing distributed, data local
> processing to OLTP. In essence, this is a proposal for a step-by-step query
> routing framework within {{Traversal}}. This proposal can work across
> machines in a cluster, threads on a machine, or in a hierarchical fashion
> machines&threads. The example presented will discuss distribution across
> machines in a cluster as its the most complicated scenario.
> Currently, an OLTP traversal executes at a particular machine (or thread) and
> pulls vertex/edge/etc. data to it accordingly in order to solve the
> traversal. In OLAP, the traversal is cloned and distributed to all machines
> in the cluster and traversals communicate with one another by sending
> {{Traversers}} (i.e. messages) between themselves ensuring data local
> processing. Given recent advancements in GremlinServer and
> {{RemoteTraversal}}, it is possible to add traverser routing to OLTP and
> thus, effect the computational paradigm of Gremlin OLAP in Gremlin OLTP with
> some added benefits not possible in Gremlin OLAP.
> Assume a 4 machine cluster and the following traversal:
> {code}
> g.V(1).out(‘knows’).has(‘age’,gt(20)).out(‘likes’).values(‘name’)
> {code}
> Every time there is a "walk" (adjacency), it is possible that the
> {{Traverser}} is no longer accessing data local to the current machine. In
> order to do data local query routing, every adjacency would feed into a
> {{PartitionStep}}. The traversal above would be cloned (via {{Bytecode}}
> distribution) across the cluster where "sibling" {{PartitionSteps}} would
> have network access to one another using the same protocol of
> {{RemoteConnection}} though called {{PartitionConnection}}. Thus, given the 4
> node cluster example, the above traversal would be overlaid as below. Note
> that {{partition()}} would not be a new step in the language, but simply
> provided here to show where {{PartitionStrategy}} would insert
> {{PartitionSteps}} into the traversal.
> {code}
> g.V(1).out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>^
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
>| |
>|
>
> __.out(‘knows’).partition().has(‘age’,gt(20)).out(‘likes’).partition().values(‘name’).partition()
> {code}
> The top traversal is called the "master traversal" and the other three
> "worker traversals." Note that this is identical to current Gremlin OLAP.
> Now, the master traversal would be the traversal that is {{.next()}}'d for
> results. So, when the "master traversal" is {{next()}}'d, {{g.V(1)}} will
> fetch {{v[1]}} and then its outgoing knows-adjacencies. These adjacent
> "reference vertices" would be fed into the first {{remote()}} and a "routing
> algorithm" would determine where in the cluster the particular vertex's data
> is. Thus, {{partition()}} ({{PartitionStep}}) serves as a router, pushing
> {{Traversers}} local to the data. Finally, note that the final
[jira] [Commented] (TINKERPOP-1569) Decompile lambdas in to regular gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695574#comment-15695574 ] Robert Dale commented on TINKERPOP-1569: Looks like your deps on JetBrains is GPLv3 which can not be included in ASL 2.0. > Decompile lambdas in to regular gremlin > --- > > Key: TINKERPOP-1569 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1569 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.3 >Reporter: Bryn Cooke > > I've been experimenting recently with decompilation and come up with this > method for decompiling lambdas: > https://github.com/BrynCooke/dice/blob/master/lambda/src/test/java/org/jglue/dice/lambda/TestDecompiler.java > Perhaps this could be useful for converting lamdas to regular gremlin? > It only works with serializable lambdas BTW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1483) PropertyMapStep returns Map but puts non String keys in it!
[
https://issues.apache.org/jira/browse/TINKERPOP-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15695551#comment-15695551
]
ASF GitHub Bot commented on TINKERPOP-1483:
---
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/446
This is interesting. I was unaware of some or didn't understand some
implementation details. Taking a step back and looking at this again, I wonder
if the original intent is more correct. Sorry @JPMoresmau
:smiley:
We have to ask what is the purpose of `Hidden`? And what is the purpose of
`T.*.getAccessor()`? Looks like `Has` step internally use `T.*.getAccessor()`
for equality tests. Is this more of an internal method or should it be exposed?
Ultimately, the question is with what or how do we expect to access `T`
tokens in a value map?
Given: `map = g.V().valueMap(true).next()`
Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`?
If the answer is `T.id` then the interface must be
If the answer is `T.id.getAccessor()` then the interface must be
In either case, there is no conflict between system-level `T` tokens (e.g.
`T.id`), as these are either Enum or `Hidden`, and user-level strings (e.g.
`id`).
> PropertyMapStep returns Map but puts non String keys in it!
> -
>
> Key: TINKERPOP-1483
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1483
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.2
>Reporter: JP Moresmau
>
> PropertyMapStep.map has return type Map, but if includeTokens is
> true:
> {code}
> if (element instanceof VertexProperty) {
> map.put(T.id, element.id());
> map.put(T.key, ((VertexProperty) element).key());
> map.put(T.value, ((VertexProperty) element).value());
> } else {
> map.put(T.id, element.id());
> map.put(T.label, element.label());
> }
> {code}
> T.id, T.key and T.value are NOT strings, so code looping through the keys in
> Java fails. toString() are missing... But do we rely on having these keys in
> other operations?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] tinkerpop issue #446: TINKERPOP-1483: valueMap should always return string k...
Github user robertdale commented on the issue: https://github.com/apache/tinkerpop/pull/446 This is interesting. I was unaware of some or didn't understand some implementation details. Taking a step back and looking at this again, I wonder if the original intent is more correct. Sorry @JPMoresmau :smiley: We have to ask what is the purpose of `Hidden`? And what is the purpose of `T.*.getAccessor()`? Looks like `Has` step internally use `T.*.getAccessor()` for equality tests. Is this more of an internal method or should it be exposed? Ultimately, the question is with what or how do we expect to access `T` tokens in a value map? Given: `map = g.V().valueMap(true).next()` Access by: `map.get(T.id)` **or** `map.get(T.id.getAccessor())`? If the answer is `T.id` then the interface must be If the answer is `T.id.getAccessor()` then the interface must be In either case, there is no conflict between system-level `T` tokens (e.g. `T.id`), as these are either Enum or `Hidden`, and user-level strings (e.g. `id`). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
