[jira] [Created] (TINKERPOP-1702) BatchGraph support in Python
Victor Genin created TINKERPOP-1702: --- Summary: BatchGraph support in Python Key: TINKERPOP-1702 URL: https://issues.apache.org/jira/browse/TINKERPOP-1702 Project: TinkerPop Issue Type: Improvement Components: driver Reporter: Victor Genin Currently there is no support of BatchGraph in python driver, or at least so it seems -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1702) BatchGraph support in Python
[
https://issues.apache.org/jira/browse/TINKERPOP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066317#comment-16066317
]
stephen mallette commented on TINKERPOP-1702:
-
There is no {{BatchGraph}} support anywhere in TinkerPop 3.x. Was there
something specific you were looking for?
> BatchGraph support in Python
>
>
> Key: TINKERPOP-1702
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1702
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Reporter: Victor Genin
>
> Currently there is no support of BatchGraph in python driver, or at least so
> it seems
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1698) Gryo 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1698: Description: Introduce Gryo 3.0. Key changes would occur to element serializers that would better handle the difference species of "detachment" and to remove unneeded registrations. (was: Introduce gryo 3.0 for 3.3.0) > Gryo 3.0 > > > Key: TINKERPOP-1698 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1698 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.2.5 >Reporter: stephen mallette >Assignee: stephen mallette > > Introduce Gryo 3.0. Key changes would occur to element serializers that would > better handle the difference species of "detachment" and to remove unneeded > registrations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1686) Make TraversalMetrics thread safe
[ https://issues.apache.org/jira/browse/TINKERPOP-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1686: Labels: breaking (was: ) > Make TraversalMetrics thread safe > - > > Key: TINKERPOP-1686 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1686 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.4 >Reporter: stephen mallette >Assignee: stephen mallette > Labels: breaking > Fix For: 3.2.6 > > > Ensure that it is possible to write to metrics from multiple threads. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TINKERPOP-1703) Make DsegEdgeOtherVertexStep non-final
Bryn Cooke created TINKERPOP-1703: - Summary: Make DsegEdgeOtherVertexStep non-final Key: TINKERPOP-1703 URL: https://issues.apache.org/jira/browse/TINKERPOP-1703 Project: TinkerPop Issue Type: Improvement Components: process Reporter: Bryn Cooke I missed this in TINKERPOP-1669. To recap, having element steps non final is helpful to implementations as they can leave the majority of the traversal steps alone, and only replace the element steps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [DISCUSS] Remaining Items for 3.3.0
hahaha - i can't win. there was other work done on Gryo 3.0 a pretty long time ago, that made it useful around Request/ResponseMessage serialization in Gremlin Server. I'd long forgotten about that. I guess I will finish up the work - the work just won't be harried by anything that had anything to do with TINKERPOP-1592. It was almost there anyway I think. On Tue, Jun 27, 2017 at 3:02 PM, Stephen Mallette wrote: > You had me at the problem with multi-properties. withDetachment() doesn't > seem to address that well and which makes this feel quite more hacky than > when it started. > > I think not doing withDetachment() reduces the need and urgency to do Gryo > 3.0. HaltedTraverserStrategy already works as does all the serialization > that goes with it. The only issue that is messed up is that I need to "fix" > TraversalMetrics serialization in Gryo 1.0, but we've never been super > consistent about versioning Gryo anyway, so i wonder if that minor break > matters on a version where we are allowing for breaks. I think i'll kill my > efforts on Gryo 3.0 for now and save some code. > > > > On Tue, Jun 27, 2017 at 11:17 AM, Marko Rodriguez > wrote: > >> Hi, >> >> In this email I will argue why TINKERPOP-1592 is a bad idea. >> >> GremlinServer does “too much.” In the future, the concept for >> GremlinServer for TinkerPop4 should be “network I/O to the Gremlin virtual >> machine.” That is it. So what is GremlinServer doing now that is bad? >> Currently GremlinServer is “detaching” elements from the graph and >> populating those elements with more data than the user requested. What do I >> mean?: >> >> g.V(1) >> >> Currently that returns a DetachedVertex which is vertex 1’s id, label, >> and all of its properties. Now here is the crazy part. What if there are 1M >> properties (e.g. timestamped multi-properties on sensor network vertices). >> Doh! However, what did the user ask for? They asked for v[1] and that is >> all they should get. This is known as ReferenceVertex. If they wanted some >> subset of the timestamped sensor network data, they should have done: >> >> g.V(1).properties(‘sensor’).has(‘timestamp’,gt(2017)) >> >> Thus, we should only return the data people explicitly ask for in the >> traversal. The TINKERPOP-1592 ticket is a hack for DetachedVertex by >> allowing users to specify withDetachment(properties:[“not_sensor”]), but >> then it is not expressive enough. Ultimately, for generality, users will >> want to specify full traversals in their withDetachment() specification. >> Now you are talking SubgraphStrategy. Dar! — and guess what, GremlinServer >> doesn’t respect SubgraphStrategy. This is the problem with everything NOT >> being traversal — once you start using the “Blueprints API” you start >> getting inconsistent behavior/functionality. Thus, GremlinServer does too >> much — just execute the traversal and return the result. >> >> Next, DetachedXXX starts to get I-N-S-A-N-E when you start talking GLVs. >> Now we have the Blueprints API implements in C#, Python, etc. N! >> GLV’s should only implement ReferenceXXX which is the bare minimum >> specification of a graph object such that it can be re-attached (referenced >> back) to the source graph. Thats it. Don’t start populating it with >> properties — “what about edges?” — “can it get the neighboring vertices >> properties too?” — “what about ...?” — if you want that data, you traverse >> to it yourself! >> >> So, what is the solution to the problem at hand — ReferenceXXX. These >> element classes are the minimal amount of data required to re-attach to the >> source graph. Thus, if you do g.V(1), you get back id/label. However, if >> you want to then get the sensor data, you do g.V(v1).properties(…). >> Moreover, there is a little hidden gem called HaltedTraverserStrategy that >> allows the user to specify their desired element class — >> https://github.com/apache/tinkerpop/blob/master/gremlin-core >> /src/main/java/org/apache/tinkerpop/gremlin/process/traversa >> l/strategy/decoration/HaltedTraverserStrategy.java < >> https://github.com/apache/tinkerpop/blob/master/gremlin-cor >> e/src/main/java/org/apache/tinkerpop/gremlin/process/travers >> al/strategy/decoration/HaltedTraverserStrategy.java>. >> >> If GremlinServer is yielding too much data, simply do this: >> >> g = g.withStrategy(HaltedTraverserStrategy.reference()) >> g.V(1) // ahh… fresh and clean. >> >> The trick to software is not to write it. If you are a software >> developer, you are not as good as the guy who runs the deli down the street >> cause guess what, he lives just fine and doesn’t write a lick of code. >> >> Marko. >> >> http://markorodriguez.com >> >> >> >> > On Jun 26, 2017, at 2:21 PM, Stephen Mallette >> wrote: >> > >> > Looking back at this thread, I think that since there were no >> objections to >> > doing "pre-releases" of GLVs I think we can postpone the test suite >> > changes. So, i'm fine with that being off the table. >> > >> > Looking at my li
[jira] [Updated] (TINKERPOP-1686) Make TraversalMetrics thread safe
[ https://issues.apache.org/jira/browse/TINKERPOP-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1686: Fix Version/s: (was: 3.2.6) 3.3.0 > Make TraversalMetrics thread safe > - > > Key: TINKERPOP-1686 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1686 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.2.4 >Reporter: stephen mallette >Assignee: stephen mallette > Labels: breaking > Fix For: 3.3.0 > > > Ensure that it is possible to write to metrics from multiple threads. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1698) Gryo 3.0
[ https://issues.apache.org/jira/browse/TINKERPOP-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1698: Description: Introduce Gryo 3.0. Better separation of domain objects from serialization format for graph elements. Dynamic serializer registrations to include those from gremlin-driver. (was: Introduce Gryo 3.0. Key changes would occur to element serializers that would better handle the difference species of "detachment" and to remove unneeded registrations.) > Gryo 3.0 > > > Key: TINKERPOP-1698 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1698 > Project: TinkerPop > Issue Type: Improvement > Components: io >Affects Versions: 3.2.5 >Reporter: stephen mallette >Assignee: stephen mallette > > Introduce Gryo 3.0. Better separation of domain objects from serialization > format for graph elements. Dynamic serializer registrations to include those > from gremlin-driver. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant
[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066425#comment-16066425
]
stephen mallette commented on TINKERPOP-1552:
-
[~jorgebg] regarding:
> It looks like tag is deprecated
i looked at that link and it didn't say there was a workaround. do you know of
a way to set the summary in nuget someway?
> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant
[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066440#comment-16066440
]
Jorge Bay commented on TINKERPOP-1552:
--
I'm not aware there is any... the {{}} tag is now used to display
as both the short summary on the website and in nuget UIs.
> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[DISCUSS] Hiding the "Blueprints API"
Hello, Throughout our documentation we show uses of the “Blueprints API” (i.e. Graph/Vertex/Edge/etc. classes & methods) as well as the use of the Traversal API (i.e. Gremlin). Enabling users to have two ways of interacting with the graph system has its problems: 1. The DetachedXXX problem — how much data should a returned vertex/edge/etc. have associated with it? 2. graph.addVertex() and g.addV() — which should I use? The first is faster but is not recommended. 3. SubgraphStrategy leaking — I get subgraphs with Gremlin, but can then directly interact with the vertex objects to see more than I should. 4. VertexProgram model — I write traversals with Traversal API, but then develop VertexPrograms with the Blueprints API. That’s weird. 5. GremlinServer returning fat objects — Serializers are created property-rich vertices and edges. The awkward HaltedTraversalStrategy solution. 6. … various permutations of these source problems. I propose that we solve this problem once and for all in TinkerPop4 as follows: There should be two “Graph APIs.” 1. Provider Graph API: This is the current Blueprints API with Graph.addVertex(), Vertex.edges(), Edge.inVertex(), etc. 3. User Graph API: This is a ReferenceXXX API. Lets talk about the second as its more novel and distinct from current practices. We should have ReferenceGraph which is simply a reference/dummy/proxy to the provider Graph API. ReferenceGraph has the following API: ReferenceGraph.open() ReferenceGraph.close() ReferenceGraph.tx() // assuming we like the current transaction model (??) ReferenceGraph.traversal() That is it. What does this entail? Assume the following traversal: g = ReferenceGraph.open(config).traversal() g.V(1).out(‘knows’) ReferenceGraph is almost like a “RemoteGraph” (RemoteStrategy) in that it makes a connection (remote or inter-JVM) to the provider Graph API. When g.V(1).out(‘knows’) executes, it is really sending the bytecode to the provider Graph for execution (as specified by the config of ReferenceGraph.open()). Thus, once it hits the provider's graph, ProviderVertex, ProviderEdge, etc. are the objects being processed. However, what the traversal’s Iterator returns is ReferenceVertex! That is, it never returns ProviderVertex. In this way, regardless if the user is going “over the wire” or within the same JVM or against a different provider’s graph database or from Gremlin-Python/C#/etc., all the vertices are simply ‘reference vertices’ (id + label). This makes it so that users never interact with the graph element objects themselves directly. They can ONLY interact with the graph via traversals! At most they can ReferenceVertex.id() and ReferenceVertex.label(). Thats it, — no mutations, not walking edges, nada! And moreover, since ReferenceXXX has enough information to re-attach to the source graph, they can always do the following to get more information: v = g.V(1).out(‘knows’).next() g.V(v).values(‘name’) This split into two Graph APIs will enables us to make a hard boundary between what the provider (vendor) needs to implement and what the user (developer) gets to access. This distinction should solve the problems articulated at the start of this email. Thoughts?, Marko. http://markorodriguez.com
[GitHub] tinkerpop pull request #641: TINKERPOP-1703: Make DsegEdgeOtherVertexStep no...
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/641
TINKERPOP-1703: Make DsegEdgeOtherVertexStep non-final
https://issues.apache.org/jira/browse/TINKERPOP-1703
The ticket really is about making {{EdgeOtherVertexStep}} non-final so
providers, like DSEGraph, can extend it accordingly.
Simple fix.
**SIDENOTE**: @dkuppitz -- I wonder if there is a more efficient way to
implement this step. I looked into using `Path.get(i)`, but it seems while it
makes less data, it is more expensive to execute (at least for `ImmutablePath`).
VOTE +1.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1703
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/641.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #641
commit 2543cb4f3d876a54585f4b4b92849c372d394f2f
Author: Marko A. Rodriguez
Date: 2017-06-28T14:15:54Z
EdgeOtherVertexStep is no longer final and can be extended by providers.
---
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-1703) Make DsegEdgeOtherVertexStep non-final
[
https://issues.apache.org/jira/browse/TINKERPOP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066560#comment-16066560
]
ASF GitHub Bot commented on TINKERPOP-1703:
---
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/641
TINKERPOP-1703: Make DsegEdgeOtherVertexStep non-final
https://issues.apache.org/jira/browse/TINKERPOP-1703
The ticket really is about making {{EdgeOtherVertexStep}} non-final so
providers, like DSEGraph, can extend it accordingly.
Simple fix.
**SIDENOTE**: @dkuppitz -- I wonder if there is a more efficient way to
implement this step. I looked into using `Path.get(i)`, but it seems while it
makes less data, it is more expensive to execute (at least for `ImmutablePath`).
VOTE +1.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1703
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/641.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #641
commit 2543cb4f3d876a54585f4b4b92849c372d394f2f
Author: Marko A. Rodriguez
Date: 2017-06-28T14:15:54Z
EdgeOtherVertexStep is no longer final and can be extended by providers.
> Make DsegEdgeOtherVertexStep non-final
> --
>
> Key: TINKERPOP-1703
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1703
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Bryn Cooke
>
> I missed this in TINKERPOP-1669.
> To recap, having element steps non final is helpful to implementations as
> they can leave the majority of the traversal steps alone, and only replace
> the element steps.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1509) Failing test case for tree serialization
[
https://issues.apache.org/jira/browse/TINKERPOP-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066569#comment-16066569
]
Marko A. Rodriguez commented on TINKERPOP-1509:
---
I suspect this is related to {{Tree}} extending {{Map}} (which was a bad idea).
I just noted a bug in {{JavaTranslator}} where I don't check to see if a
{{Map}} is a {{Tree}} and as such, may turn {{Tree}}s to {{Map}}s inadvertently.
> Failing test case for tree serialization
>
>
> Key: TINKERPOP-1509
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1509
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>
> The failure only seems to happen in some environments. I've ignored the test
> for now:
> {code}
> org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0Test
> shouldSerializeToTreeJson
> org.apache.tinkerpop.gremlin.tinkergraph.structure.TinkerGraphGraphSONSerializerV2d0Test.deserializersTestsTree
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TINKERPOP-1704) XXXTranslators are not being respective of BulkSet and Tree.
Marko A. Rodriguez created TINKERPOP-1704:
-
Summary: XXXTranslators are not being respective of BulkSet and
Tree.
Key: TINKERPOP-1704
URL: https://issues.apache.org/jira/browse/TINKERPOP-1704
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.5
Reporter: Marko A. Rodriguez
Assignee: Marko A. Rodriguez
After working on TINKERPOP-1701, I note that the {{XXXTranslators}} are not
smart about {{BulkSet}} and {{Tree}} and may inadvertently translate them to
{{HashSet}} and {{HashMap}}, respectively. Dar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop pull request #642: TINKERPOP-1704: XXXTranslators are not being re...
GitHub user okram opened a pull request: https://github.com/apache/tinkerpop/pull/642 TINKERPOP-1704: XXXTranslators are not being respective of BulkSet and Tree. https://issues.apache.org/jira/browse/TINKERPOP-1704 `JavaTranslator` would convert `Tree` to `HashMap` and `BulkSet` to `HashSet`. While passing in such objects through `Bytecode` is low probability, it is still good to cover this corner case (especially for `Tree`, where the semantics are a bit different than `Map`). VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1704 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/642.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #642 commit 506b921c947a9ec8536bd0e739b2df3d2b5440ae Author: Marko A. Rodriguez Date: 2017-06-28T14:39:37Z JavaTranslator is now smart about handling BulkSet and Tree in Bytecode. This is a low probability usage, but a usage none-the-less... --- 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-1704) XXXTranslators are not being respective of BulkSet and Tree.
[
https://issues.apache.org/jira/browse/TINKERPOP-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066608#comment-16066608
]
ASF GitHub Bot commented on TINKERPOP-1704:
---
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/642
TINKERPOP-1704: XXXTranslators are not being respective of BulkSet and Tree.
https://issues.apache.org/jira/browse/TINKERPOP-1704
`JavaTranslator` would convert `Tree` to `HashMap` and `BulkSet` to
`HashSet`. While passing in such objects through `Bytecode` is low probability,
it is still good to cover this corner case (especially for `Tree`, where the
semantics are a bit different than `Map`).
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1704
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/642.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #642
commit 506b921c947a9ec8536bd0e739b2df3d2b5440ae
Author: Marko A. Rodriguez
Date: 2017-06-28T14:39:37Z
JavaTranslator is now smart about handling BulkSet and Tree in Bytecode.
This is a low probability usage, but a usage none-the-less...
> XXXTranslators are not being respective of BulkSet and Tree.
>
>
> Key: TINKERPOP-1704
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1704
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> After working on TINKERPOP-1701, I note that the {{XXXTranslators}} are not
> smart about {{BulkSet}} and {{Tree}} and may inadvertently translate them to
> {{HashSet}} and {{HashMap}}, respectively. Dar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1702) BatchGraph support in Python
[ https://issues.apache.org/jira/browse/TINKERPOP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066616#comment-16066616 ] Victor Genin commented on TINKERPOP-1702: - It was present in 3.0.0 [http://tinkerpop.apache.org/javadocs/3.0.0.M8-incubating/full/org/apache/tinkerpop/gremlin/structure/util/batch/BatchGraph.html] and there is [https://github.com/tinkerpop/blueprints/wiki/Batch-Implementation], but indeed it's absent in 3.2.5 [http://tinkerpop.apache.org/javadocs/3.2.5/full/] Any reason why? Or a follow up question, how do I add 1K/10K/100K nodes and edges in one call? > BatchGraph support in Python > > > Key: TINKERPOP-1702 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1702 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Victor Genin > > Currently there is no support of BatchGraph in python driver, or at least so > it seems -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1693) Tree may produce incorrect results when nodes are not unique
[
https://issues.apache.org/jira/browse/TINKERPOP-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066615#comment-16066615
]
Marko A. Rodriguez commented on TINKERPOP-1693:
---
This sucks... I don't know how to solve that. Is there such thing as a
{{MultiKeyLinkedHashMap}} ???
> Tree may produce incorrect results when nodes are not unique
>
>
> Key: TINKERPOP-1693
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1693
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.2.5
>Reporter: stephen mallette
>
> Consider the following:
> {code}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V(1).repeat(out()).emit().tree()
> ==>[v[1]:[v[2]:[],v[3]:[],v[4]:[v[3]:[],v[5]:[
> gremlin> g.V(1).repeat(out()).emit().tree().by(label)
> ==>[person:[software:[],person:[software:[
> gremlin> g.V(1).repeat(out()).emit().tree().by("name")
> ==>[marko:[vadas:[],josh:[ripple:[],lop:[]],lop:[]]]
> {code}
> Since {{Tree}} extends {{HashMap}} we end up with keys having to be unique
> and when they aren't we lose some of the tree structure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TINKERPOP-1702) BatchGraph support in Python
[ https://issues.apache.org/jira/browse/TINKERPOP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066616#comment-16066616 ] Victor Genin edited comment on TINKERPOP-1702 at 6/28/17 2:49 PM: -- It was present in 3.0.0 [http://tinkerpop.apache.org/javadocs/3.0.0.M8-incubating/full/org/apache/tinkerpop/gremlin/structure/util/batch/BatchGraph.html] and there is a wiki mentioning it [https://github.com/tinkerpop/blueprints/wiki/Batch-Implementation], but indeed it's absent in 3.2.5 [http://tinkerpop.apache.org/javadocs/3.2.5/full/] Any reason why? Or a follow up question, how do I add 1K/10K/100K nodes and edges in one call? was (Author: victor.genin): It was present in 3.0.0 [http://tinkerpop.apache.org/javadocs/3.0.0.M8-incubating/full/org/apache/tinkerpop/gremlin/structure/util/batch/BatchGraph.html] and there is [https://github.com/tinkerpop/blueprints/wiki/Batch-Implementation], but indeed it's absent in 3.2.5 [http://tinkerpop.apache.org/javadocs/3.2.5/full/] Any reason why? Or a follow up question, how do I add 1K/10K/100K nodes and edges in one call? > BatchGraph support in Python > > > Key: TINKERPOP-1702 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1702 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Reporter: Victor Genin > > Currently there is no support of BatchGraph in python driver, or at least so > it seems -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (TINKERPOP-1702) BatchGraph support in Python
[
https://issues.apache.org/jira/browse/TINKERPOP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1702.
---
Resolution: Won't Do
yeah - that's long gone. in general, massive batch loads (say millions of
things) should be done with OLAP -
http://tinkerpop.apache.org/docs/current/reference/#hadoop-gremlin and anything
less is probably best done with a groovy script. If you want to do it from
python i would just write a parameterized script like:
{code}
data.each {
g.addV('name', it.name, 'age', it.age).iterate()
}
{code}
where "data" is a parameter you pass with the script. "data" is just a
{{List}} and the number of maps represents your batch size. Use
sessionless requests so that Gremlin Server auto-commits. If you have further
follow up questions, please ask them on the gremlin-users mailing list - thanks.
> BatchGraph support in Python
>
>
> Key: TINKERPOP-1702
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1702
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Reporter: Victor Genin
>
> Currently there is no support of BatchGraph in python driver, or at least so
> it seems
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop issue #640: TINKERPOP-1694 Deprecated useMapperFromGraph
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/640 VOTE +1 --- 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-1694) Deprecate useMapperFromGraph
[ https://issues.apache.org/jira/browse/TINKERPOP-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066628#comment-16066628 ] ASF GitHub Bot commented on TINKERPOP-1694: --- Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/640 VOTE +1 > Deprecate useMapperFromGraph > > > Key: TINKERPOP-1694 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1694 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.5 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: deprecation > > Deprecate useMapperFromGraph -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop issue #634: TINKERPOP-741 Deprecated Transaction.submit(Function)
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/634 VOTE +1. --- 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. ---
[GitHub] tinkerpop issue #633: TINKERPOP-741 (master) Removed deprecated transaction ...
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/633 VOTE +1 --- 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-741) Remove Options For Transaction Retry
[
https://issues.apache.org/jira/browse/TINKERPOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066631#comment-16066631
]
ASF GitHub Bot commented on TINKERPOP-741:
--
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/633
VOTE +1
> Remove Options For Transaction Retry
>
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like
> this:
> {code}
> public Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow
> mutation operations to execute over a {{Traversal}}. It also doesn't account
> for workload constructed over multiple requests in a session to Gremlin
> Server too well.
> Maybe we do something like:
> {code}
> public Workload submit(final Function... work);
> public Workload submit(final Function... work);
> public Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could
> automate transaction retry by inserting scripts to a list variable on the
> server side until client-side {{commit()}} at which point that list could be
> {{submit}} for retry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-741) Remove Options For Transaction Retry
[
https://issues.apache.org/jira/browse/TINKERPOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066630#comment-16066630
]
ASF GitHub Bot commented on TINKERPOP-741:
--
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/634
VOTE +1.
> Remove Options For Transaction Retry
>
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like
> this:
> {code}
> public Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow
> mutation operations to execute over a {{Traversal}}. It also doesn't account
> for workload constructed over multiple requests in a session to Gremlin
> Server too well.
> Maybe we do something like:
> {code}
> public Workload submit(final Function... work);
> public Workload submit(final Function... work);
> public Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could
> automate transaction retry by inserting scripts to a list variable on the
> server side until client-side {{commit()}} at which point that list could be
> {{submit}} for retry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop pull request #643: TINKERPOP-1701: HaltedTraverserStrategy should ...
GitHub user okram opened a pull request: https://github.com/apache/tinkerpop/pull/643 TINKERPOP-1701: HaltedTraverserStrategy should recurse into collections for detachment. https://issues.apache.org/jira/browse/TINKERPOP-1701 `HaltedTraverserStrategy` is used by serializing systems (e.g. GremlinServer, OLAP) to decide how to format the result set. For instance, are the objects `DetachedXXX` or `ReferenceXXX`. In order to make this functionality generalized to objects within collections, `DetachedFactory` and `ReferenceFactory` were updated to handle `Tree`, `Map`, `BulkSet`, `Set`, and `List` (in any arbitrarily nested configuration). Test cases added, and stuff passes. VOTE +1. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1701 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/643.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #643 commit 6e2ebb52fdaa477e93a98d6c7c28b4ce5ed9bdb5 Author: Marko A. Rodriguez Date: 2017-06-27T19:51:47Z added colleciton handling to XXXFactory.detach(). This will ensure that collection nested graph elements get detached accordingly. commit d16d0df5c64f6da04c6a11c9403273f30eb264d4 Author: Marko A. Rodriguez Date: 2017-06-27T20:14:22Z added test cases that verify that nested collection detachment works for Lists, Sets, and Maps (and any arbitrary nest of those collections within themselves). commit 7d54b1814937da8693b8d45498b2f56b941a9caf Author: Marko A. Rodriguez Date: 2017-06-27T20:23:12Z doh. needed to tweak the ReferenceFactory test as properties don't come over. commit 12de6fbf49028072ffb0933776c516e1bf1e9763 Author: Marko A. Rodriguez Date: 2017-06-27T20:29:09Z add test cases to HaltedTraversaerStrategyTest to verify property collection handling during detachment. commit c01b27ea870b15464a263254248b177a8bd0d9d4 Author: Marko A. Rodriguez Date: 2017-06-27T20:56:48Z the plot thickens with BulkSet and Tree needing special handling during detachment. @spmallette was right about the rabbit hole. Fortuantely, we have lots of test cases that failed cause of not handling these collections correctly. So that is a win. commit f43d1e2dd1635726588bd9c67bc312f8f52c07c6 Author: Marko A. Rodriguez Date: 2017-06-28T14:11:37Z minor nothing. need to switch branches. commit 601f9c3062e78bec8e23d695a75cedb1e3381229 Author: Marko A. Rodriguez Date: 2017-06-28T15:02:49Z being smarter about the collection sizes on object creation. --- 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-1701) HaltedTraverserStrategy should recurse into collections for detachment.
[
https://issues.apache.org/jira/browse/TINKERPOP-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066641#comment-16066641
]
ASF GitHub Bot commented on TINKERPOP-1701:
---
GitHub user okram opened a pull request:
https://github.com/apache/tinkerpop/pull/643
TINKERPOP-1701: HaltedTraverserStrategy should recurse into collections for
detachment.
https://issues.apache.org/jira/browse/TINKERPOP-1701
`HaltedTraverserStrategy` is used by serializing systems (e.g.
GremlinServer, OLAP) to decide how to format the result set. For instance, are
the objects `DetachedXXX` or `ReferenceXXX`. In order to make this
functionality generalized to objects within collections, `DetachedFactory` and
`ReferenceFactory` were updated to handle `Tree`, `Map`, `BulkSet`, `Set`, and
`List` (in any arbitrarily nested configuration). Test cases added, and stuff
passes.
VOTE +1.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1701
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/643.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #643
commit 6e2ebb52fdaa477e93a98d6c7c28b4ce5ed9bdb5
Author: Marko A. Rodriguez
Date: 2017-06-27T19:51:47Z
added colleciton handling to XXXFactory.detach(). This will ensure that
collection nested graph elements get detached accordingly.
commit d16d0df5c64f6da04c6a11c9403273f30eb264d4
Author: Marko A. Rodriguez
Date: 2017-06-27T20:14:22Z
added test cases that verify that nested collection detachment works for
Lists, Sets, and Maps (and any arbitrary nest of those collections within
themselves).
commit 7d54b1814937da8693b8d45498b2f56b941a9caf
Author: Marko A. Rodriguez
Date: 2017-06-27T20:23:12Z
doh. needed to tweak the ReferenceFactory test as properties don't come
over.
commit 12de6fbf49028072ffb0933776c516e1bf1e9763
Author: Marko A. Rodriguez
Date: 2017-06-27T20:29:09Z
add test cases to HaltedTraversaerStrategyTest to verify property
collection handling during detachment.
commit c01b27ea870b15464a263254248b177a8bd0d9d4
Author: Marko A. Rodriguez
Date: 2017-06-27T20:56:48Z
the plot thickens with BulkSet and Tree needing special handling during
detachment. @spmallette was right about the rabbit hole. Fortuantely, we have
lots of test cases that failed cause of not handling these collections
correctly. So that is a win.
commit f43d1e2dd1635726588bd9c67bc312f8f52c07c6
Author: Marko A. Rodriguez
Date: 2017-06-28T14:11:37Z
minor nothing. need to switch branches.
commit 601f9c3062e78bec8e23d695a75cedb1e3381229
Author: Marko A. Rodriguez
Date: 2017-06-28T15:02:49Z
being smarter about the collection sizes on object creation.
> HaltedTraverserStrategy should recurse into collections for detachment.
> ---
>
> Key: TINKERPOP-1701
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1701
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> We need to make sure that {{HaltedTraverserStrategy}} recurses into
> collections. This will be elegantly handled by updated {{DetachedFactory}}
> and {{ReferenceFactory}} accordingly.
> For instance:
> {code}
> public static D detach(final Object object) {
> if (object instanceof Element) {
> return (D) ReferenceFactory.detach((Element) object);
> } else if (object instanceof Property) {
> return (D) ReferenceFactory.detach((Property) object);
> } else if (object instanceof Path) {
> return (D) ReferenceFactory.detach((Path) object);
> } else if (object instanceof List) {
> final List list = new ArrayList();
> for (final Object item : (List) object) {
> list.add(ReferenceFactory.detach(item));
> }
> return (D) list;
> } else if (object instanceof Set) {
> final Set set = object instanceof LinkedHashSet ? new
> LinkedHashSet() : new HashSet();
> for (final Object item : (Set) object) {
> set.add(ReferenceFactory.detach(item));
> }
> return (D) set;
> } else if (object instanceof Map) {
> final Map map = object instanceof LinkedHashMap ? new
> LinkedHashMap() : new HashMap();
> for (final Map.Entry entry : ((Map Object>) object).entrySet()) {
> map.put(ReferenceFactory.detach(entry.getKey()),
> ReferenceFactory
[jira] [Updated] (TINKERPOP-1703) Make EdgeOtherVertexStep non-final
[ https://issues.apache.org/jira/browse/TINKERPOP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryn Cooke updated TINKERPOP-1703: -- Summary: Make EdgeOtherVertexStep non-final (was: Make DsegEdgeOtherVertexStep non-final) > Make EdgeOtherVertexStep non-final > -- > > Key: TINKERPOP-1703 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1703 > Project: TinkerPop > Issue Type: Improvement > Components: process >Reporter: Bryn Cooke > > I missed this in TINKERPOP-1669. > To recap, having element steps non final is helpful to implementations as > they can leave the majority of the traversal steps alone, and only replace > the element steps. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant
[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066908#comment-16066908
]
stephen mallette commented on TINKERPOP-1552:
-
As of right now, gremlin-dotnet is deploying nicely to nuget's staging site and
has support for "SNAPSHOTs":
https://staging.nuget.org/packages/Gremlin.Net/
I have the csproj file updating as part of the maven build and figured out how
to get the NuGet.Config working properly with the api key. I will rebase this
branch and tp32-glv , do a full build and if all good I think we can consider
offering this up for pull request to the tp32 release branch. Once merged we
can get an official development release out there to the official nuget repo.
> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
> Issue Type: Improvement
> Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of
> the trickier bits to deal with.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] tinkerpop pull request #634: TINKERPOP-741 Deprecated Transaction.submit(Fun...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/634 --- 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. ---
[GitHub] tinkerpop pull request #633: TINKERPOP-741 (master) Removed deprecated trans...
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/633 --- 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-741) Remove Options For Transaction Retry
[
https://issues.apache.org/jira/browse/TINKERPOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066941#comment-16066941
]
ASF GitHub Bot commented on TINKERPOP-741:
--
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/633
> Remove Options For Transaction Retry
>
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like
> this:
> {code}
> public Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow
> mutation operations to execute over a {{Traversal}}. It also doesn't account
> for workload constructed over multiple requests in a session to Gremlin
> Server too well.
> Maybe we do something like:
> {code}
> public Workload submit(final Function... work);
> public Workload submit(final Function... work);
> public Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could
> automate transaction retry by inserting scripts to a list variable on the
> server side until client-side {{commit()}} at which point that list could be
> {{submit}} for retry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-741) Remove Options For Transaction Retry
[
https://issues.apache.org/jira/browse/TINKERPOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066942#comment-16066942
]
ASF GitHub Bot commented on TINKERPOP-741:
--
Github user asfgit closed the pull request at:
https://github.com/apache/tinkerpop/pull/634
> Remove Options For Transaction Retry
>
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Submitting a transactional workload for automatic retry currently looks like
> this:
> {code}
> public Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow
> mutation operations to execute over a {{Traversal}}. It also doesn't account
> for workload constructed over multiple requests in a session to Gremlin
> Server too well.
> Maybe we do something like:
> {code}
> public Workload submit(final Function... work);
> public Workload submit(final Function... work);
> public Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could
> automate transaction retry by inserting scripts to a list variable on the
> server side until client-side {{commit()}} at which point that list could be
> {{submit}} for retry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (TINKERPOP-741) Remove Options For Transaction Retry
[
https://issues.apache.org/jira/browse/TINKERPOP-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-741.
--
Resolution: Done
Assignee: stephen mallette
Fix Version/s: 3.2.6
> Remove Options For Transaction Retry
>
>
> Key: TINKERPOP-741
> URL: https://issues.apache.org/jira/browse/TINKERPOP-741
> Project: TinkerPop
> Issue Type: Improvement
> Components: structure
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.6
>
>
> Submitting a transactional workload for automatic retry currently looks like
> this:
> {code}
> public Workload submit(final Function work);
> {code}
> but that doesn't take into account relatively recent changes that allow
> mutation operations to execute over a {{Traversal}}. It also doesn't account
> for workload constructed over multiple requests in a session to Gremlin
> Server too well.
> Maybe we do something like:
> {code}
> public Workload submit(final Function... work);
> public Workload submit(final Function... work);
> public Workload submit(final Traversal... work);
> {code}
> I suppose it might need to return a {{List}} or something like that so
> that each piece of the transaction could maintain its own result.
> With respect to Gremlin Server and in-session requests, a driver could
> automate transaction retry by inserting scripts to a list variable on the
> server side until client-side {{commit()}} at which point that list could be
> {{submit}} for retry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1694) Deprecate useMapperFromGraph
[ https://issues.apache.org/jira/browse/TINKERPOP-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067064#comment-16067064 ] ASF GitHub Bot commented on TINKERPOP-1694: --- Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/640 > Deprecate useMapperFromGraph > > > Key: TINKERPOP-1694 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1694 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.5 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: deprecation > > Deprecate useMapperFromGraph -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] tinkerpop pull request #640: TINKERPOP-1694 Deprecated useMapperFromGraph
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/640 --- 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] [Closed] (TINKERPOP-1694) Deprecate useMapperFromGraph
[ https://issues.apache.org/jira/browse/TINKERPOP-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette closed TINKERPOP-1694. --- Resolution: Done Fix Version/s: 3.2.6 > Deprecate useMapperFromGraph > > > Key: TINKERPOP-1694 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1694 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.5 >Reporter: stephen mallette >Assignee: stephen mallette >Priority: Minor > Labels: deprecation > Fix For: 3.2.6 > > > Deprecate useMapperFromGraph -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant
[ https://issues.apache.org/jira/browse/TINKERPOP-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067074#comment-16067074 ] stephen mallette commented on TINKERPOP-1489: - Just rebased and got this branch up to date. > Provide a Javascript Gremlin Language Variant > - > > Key: TINKERPOP-1489 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1489 > Project: TinkerPop > Issue Type: Improvement > Components: language-variant >Reporter: Jorge Bay > > It would be nice to have a Javascript Gremlin Language Variant that could > work with any ES5 runtime, specially the ones that support > [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js. > Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but > provides [additional > extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] > making modular JavaScript possible. Nashorn should be supported in order to > run glv tests under the same infrastructure (JDK8). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Gremlin.NET GLV
I just got a good docker build of the Gremlin.NET GLV on TINKERPOP-1552. I plan to give it a final look over tomorrow and then submit the pull request to the tp32 branch. Once it is merged we can do a "SNAPSHOT" release. As with other, SNAPSHOT releases this will be for convenience packaging for developers to play with and not something for general consumption, so we shouldn't need a VOTE thread going or anything like that. Big thanks to Florian Hockmann and Jorge Bay Gondra for helping get this branch to where it is now.
[GitHub] tinkerpop issue #618: TINKERPOP-915 Add combined handler for Http and Websoc...
Github user krlohnes commented on the issue: https://github.com/apache/tinkerpop/pull/618 @spmallete I refactored the channelizer tests and removed some elsewhere when I thought they were appropriately replaced. I'm ultimately not all too familiar with Java NIO. I added it as another channelizer test, but I can delete that test class and the associated code in the abstract test class as it really only runs a single test. I wasn't quite sure what the best way to go with that was. I also added in the doc changes. --- 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-915) Gremlin Server supports REST and Websockets simultanteously
[
https://issues.apache.org/jira/browse/TINKERPOP-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067539#comment-16067539
]
ASF GitHub Bot commented on TINKERPOP-915:
--
Github user krlohnes commented on the issue:
https://github.com/apache/tinkerpop/pull/618
@spmallete I refactored the channelizer tests and removed some elsewhere
when I thought they were appropriately replaced. I'm ultimately not all too
familiar with Java NIO. I added it as another channelizer test, but I can
delete that test class and the associated code in the abstract test class as it
really only runs a single test. I wasn't quite sure what the best way to go
with that was. I also added in the doc changes.
> Gremlin Server supports REST and Websockets simultanteously
> ---
>
> Key: TINKERPOP-915
> URL: https://issues.apache.org/jira/browse/TINKERPOP-915
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>
> Develop a {{Channelizer}} that allows REST and Websockets to be configured at
> the same time. I've personally tried to do this on a couple of attempts
> while following a Netty sample, but I've never been able to get it to work.
> Perhaps folks like [~pluradj] or [~dmill] would like to give it a go some
> day? :)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
