Re: [DISCUSS] bothE() on self-reference

2017-10-25 Thread Robert Dale 
I think that bothE() == union(outE(),inE()) and outE().count() +
inE().count() == bothE().count().  If you don't want the self-referencing
edge to be returned twice, then either make it a unidirected edge (if
supported) so that it would still satisfy the two previous condition or
dedup(). In either case, it's left to the user to determine what edges are
returned.

Also, I think it makes sense that g.E() == g.V().outE().  It should not be
g.V().inE() due to potential for unidirected edges.


Robert Dale

On Wed, Oct 25, 2017 at 9:32 AM, Daniel Kuppitz  wrote:

> IMO it should return the edge only once.
>
> Cheers,
> Daniel
>
>
> On Wed, Oct 25, 2017 at 5:47 AM, Stephen Mallette 
> wrote:
>
> > The test suite doesn't seem to enforce behavior related to self-relating
> > edges. TinkerGraph does this:
> >
> > gremlin> g = TinkerGraph.open().traversal()
> > ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> > gremlin> g.addV().as('a').addE('self').to('a')
> > ==>e[1][0-self->0]
> > gremlin> g.E()
> > ==>e[1][0-self->0]
> > gremlin> g.V().bothE().count()
> > ==>2
> >
> > Should bothE() return 2 in this case or 1? I think that we've said in the
> > past that g.E() is the same as g.V().outE() or g.V().inE(), but not
> > necessarily g.V().bothE().  Thoughts?
> >
>

[jira] [Commented] (TINKERPOP-1798) MutationListener.vertexPropertyChanged oldValue should be a VertexProperty

2017-10-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219795#comment-16219795
 ] 

ASF GitHub Bot commented on TINKERPOP-1798:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/737
  
VOTE +1


> MutationListener.vertexPropertyChanged oldValue should be a VertexProperty
> --
>
> Key: TINKERPOP-1798
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1798
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Bryn Cooke
>Assignee: stephen mallette
>Priority: Minor
>  Labels: deprecation
>
> Currently the signature looks like this:
> {noformat}
> public void vertexPropertyChanged(final Vertex element, final Property 
> oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
> {noformat}
> But should probably be:
> {noformat}
> public void vertexPropertyChanged(final Vertex element, final VertexProperty 
> oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #737: TINKERPOP-1798 Fix signature of MutationListener.verte...

2017-10-25 Thread robertdale 
Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/737
  
VOTE +1


---

[jira] [Commented] (TINKERPOP-1791) GremlinDsl custom step with generic end type produces invalid code in __.java

2017-10-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219764#comment-16219764
 ] 

ASF GitHub Bot commented on TINKERPOP-1791:
---

Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/736
  
VOTE +1


> GremlinDsl custom step with generic end type produces invalid code in __.java
> -
>
> Key: TINKERPOP-1791
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1791
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.5
>Reporter: Severin Stampler
>
> I'm trying the create a custom step to perform a full-text search in an 
> external index and return the matching vertices or edges, like this:
> {code:java}
> @GremlinDsl(traversalSource = 
> "com.saillabs.mediaminer.mmgraphdsl.MMGraphTraversalSourceDsl")
> public interface MMGraphTraversalDsl extends GraphTraversal.Admin 
> {
>   public default GraphTraversal search(String field, String query) {
>   //TODO:
>   // Find vertex ids matching the search query in external index
>   
>   Set vids = new HashSet<>();
>   // for now add some hardcoded vertex ids
>   vids.add("vertex1");
>   vids.add("vertex2");
>   
> return hasId(P.within(vids));
> }
>   
> }
> {code}
> The code seems correct in my point of view, but the generated code in the 
> __.java is not compilable. It produces this error:
> {noformat}
> [ERROR] 
> /C:/svn/start/mm/mmserver/server/mvn/mmgraphdsl/target/generated-sources/annotations/com/saillabs/mediaminer/mmgraphdsl/__.java:[41,41]
>  cannot find symbol
> [ERROR] symbol:   class E
> [ERROR] location: class com.saillabs.mediaminer.mmgraphdsl.__
> {noformat}
> The generated code is this:
> {code:java}
> public static  MMGraphTraversal search(String field, String query) {
> return __.start().search(field,query);
>   }
> {code}
> I think the correct generated code should look like this:
> {code:java}
> public static  MMGraphTraversal search(String field, String query) {
> return __.start().search(field,query);
>   }
> {code}
> I think it's a bug in the GremlinDsl code generator, however, I may be wrong. 
> Any help is appreciated.
> Thanks, br
> Severin



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #736: TINKERPOP-1791 Added GremlinDsl.AnonymousMethod annota...

2017-10-25 Thread robertdale 
Github user robertdale commented on the issue:

https://github.com/apache/tinkerpop/pull/736
  
VOTE +1


---

[jira] [Commented] (TINKERPOP-1791) GremlinDsl custom step with generic end type produces invalid code in __.java

2017-10-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219605#comment-16219605
 ] 

ASF GitHub Bot commented on TINKERPOP-1791:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/736
  
VOTE: +1


> GremlinDsl custom step with generic end type produces invalid code in __.java
> -
>
> Key: TINKERPOP-1791
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1791
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.5
>Reporter: Severin Stampler
>
> I'm trying the create a custom step to perform a full-text search in an 
> external index and return the matching vertices or edges, like this:
> {code:java}
> @GremlinDsl(traversalSource = 
> "com.saillabs.mediaminer.mmgraphdsl.MMGraphTraversalSourceDsl")
> public interface MMGraphTraversalDsl extends GraphTraversal.Admin 
> {
>   public default GraphTraversal search(String field, String query) {
>   //TODO:
>   // Find vertex ids matching the search query in external index
>   
>   Set vids = new HashSet<>();
>   // for now add some hardcoded vertex ids
>   vids.add("vertex1");
>   vids.add("vertex2");
>   
> return hasId(P.within(vids));
> }
>   
> }
> {code}
> The code seems correct in my point of view, but the generated code in the 
> __.java is not compilable. It produces this error:
> {noformat}
> [ERROR] 
> /C:/svn/start/mm/mmserver/server/mvn/mmgraphdsl/target/generated-sources/annotations/com/saillabs/mediaminer/mmgraphdsl/__.java:[41,41]
>  cannot find symbol
> [ERROR] symbol:   class E
> [ERROR] location: class com.saillabs.mediaminer.mmgraphdsl.__
> {noformat}
> The generated code is this:
> {code:java}
> public static  MMGraphTraversal search(String field, String query) {
> return __.start().search(field,query);
>   }
> {code}
> I think the correct generated code should look like this:
> {code:java}
> public static  MMGraphTraversal search(String field, String query) {
> return __.start().search(field,query);
>   }
> {code}
> I think it's a bug in the GremlinDsl code generator, however, I may be wrong. 
> Any help is appreciated.
> Thanks, br
> Severin



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #736: TINKERPOP-1791 Added GremlinDsl.AnonymousMethod annota...

2017-10-25 Thread dkuppitz 
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/736
  
VOTE: +1


---

[jira] [Commented] (TINKERPOP-1798) MutationListener.vertexPropertyChanged oldValue should be a VertexProperty

2017-10-25 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219554#comment-16219554
 ] 

ASF GitHub Bot commented on TINKERPOP-1798:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/737
  
VOTE: +1


> MutationListener.vertexPropertyChanged oldValue should be a VertexProperty
> --
>
> Key: TINKERPOP-1798
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1798
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Bryn Cooke
>Assignee: stephen mallette
>Priority: Minor
>  Labels: deprecation
>
> Currently the signature looks like this:
> {noformat}
> public void vertexPropertyChanged(final Vertex element, final Property 
> oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
> {noformat}
> But should probably be:
> {noformat}
> public void vertexPropertyChanged(final Vertex element, final VertexProperty 
> oldValue, final Object setValue, final Object... vertexPropertyKeyValues);
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] tinkerpop issue #737: TINKERPOP-1798 Fix signature of MutationListener.verte...

2017-10-25 Thread dkuppitz 
Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/737
  
VOTE: +1


---

Re: [DISCUSS] gremlinpython 3.2.7rc1 and 3.3.1rc1

2017-10-25 Thread David Brown 
+1 definitely helps me out

On Wed, Oct 25, 2017 at 1:12 PM, Stephen Mallette  wrote:
> I'd like to propose that we do release candidates of gremlinpython from
> both master and tp32. We're not quite ready for a full official release as
> of yet (personally, I'd like to see .NET ready to go before we do that),
> but we did just fix some bugs in gremlinpython around serialization and
> dependencies that would be helpful to developers working on the bleeding
> edge of things if we had a release candidate out there.
>
> If there are no objections in the next 72 hours (Saturday October 28th,
> 2017, 4pm EST) I'll assume lazy consensus and proceed with deploying:
> 3.2.7rc1 and 3.3.1rc1
>
> Thanks,
>
> Stephen



-- 
David M. Brown
R.A. CulturePlex Lab, Western University

[DISCUSS] gremlinpython 3.2.7rc1 and 3.3.1rc1

2017-10-25 Thread Stephen Mallette 
I'd like to propose that we do release candidates of gremlinpython from
both master and tp32. We're not quite ready for a full official release as
of yet (personally, I'd like to see .NET ready to go before we do that),
but we did just fix some bugs in gremlinpython around serialization and
dependencies that would be helpful to developers working on the bleeding
edge of things if we had a release candidate out there.

If there are no objections in the next 72 hours (Saturday October 28th,
2017, 4pm EST) I'll assume lazy consensus and proceed with deploying:
3.2.7rc1 and 3.3.1rc1

Thanks,

Stephen

[Blog Post] Gremlin DSLs in Python with DSE Graph

2017-10-25 Thread Stephen Mallette 
Hello TinkerPop,

I've just published another blog post on DSLs that you might find
interesting:

https://academy.datastax.com/content/gremlin-dsls-python-dse-graph

It focuses on what I think are guidelines that I believe are useful in
designing your Gremlin DSLs, so it is a bit different than my first post
which focused more on just their benefits.

Enjoy!

[jira] [Created] (TINKERPOP-1809) Process tests shouldn't modify toy data

2017-10-25 Thread stephen mallette (JIRA) 
stephen mallette created TINKERPOP-1809:
---

 Summary: Process tests shouldn't modify toy data
 Key: TINKERPOP-1809
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1809
 Project: TinkerPop
  Issue Type: Improvement
  Components: test-suite
Affects Versions: 3.2.6
Reporter: stephen mallette
Assignee: stephen mallette
Priority: Minor


While working on TINKERPOP-1784 i noticed that process test suites modify the 
data in toy graphs. That works in the java suite because we can easily and 
quickly reload toy graph data between tests (though it can be expensive for 
some graphs). For GLVs it's slow and non-trivial to do this reload. To be 
consistent in the tests (especially while we have both test suites in place) we 
should make the java suite behave like the GLV and not mutate the static toy 
graphs so that they don't need to be cleared between runs. This might be 
helpful to java test suite users as well as it could given them a chance to 
speed up their builds.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] GLV Test Suite

2017-10-25 Thread Jorge Bay Gondra 
I've been looking over the current test scenarios on the TINKERPOP-1784
branch, with the C# GLV test suite in mind, and oh man that's an impressive
amount of scenarios!

So far, I have a suggestion.

Instead of

  Scenario: g_V_fold_countXlocalX
Given the modern graph
And the traversal of
  """
  g.V().fold().count(Scope.local)
  """

We could use

  Scenario: g_V_fold_countXlocalX
Given the modern graph
And parameter 1 being an enum
  """
  Scope.local
  """
And the traversal of
  """
  g.V().fold().count(param1)
  """

That way we can exclude enums from possible parameter values, narrowing
down the amount of types of parameters allowed, ie: const numeric, const
strings (wrapped in double quotes), traversals (starting with `__`) , ...,
making parsing the traversal a little easier.


On Thu, Oct 12, 2017 at 8:54 PM, Stephen Mallette 
wrote:

> Just a quick update on this item - it continues
>
> Went down a bad path earlier in the week and ended up shelving a lot of
> work - ended up just coded into a corner. Anyway, I've not really changed
> much in the implementation, but I've still not reached a point where the
> addition of a new .feature files comes without meeting some new type of
> assertion that has to be dealt with. This ends up slowing down progress on
> porting over the tests. Please feel free to peruse the latest changes on
> the branch and let me know if there's any feedback.
>
>
>
> On Fri, Sep 29, 2017 at 12:05 PM, Stephen Mallette 
> wrote:
>
> > I did some pretty heavy refactoring to the python test logic (altered a
> > bit by some revision of the gherkin feature file language) and the result
> > is a much more simplified test logic file:
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-python/src/main/jython/radish/feature_steps.py
> >
> > About 120 lines of code (down from about 170). If you include the test
> > logic "setup" file:
> >
> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> > gremlin-python/src/main/jython/radish/terrain.py
> >
> > we end up with about 250 lines of test logic total (take out the
> > comment/license and we're probably well under 200 total - not too bad). I
> > think I'm closing in on the end to infrastructure building here so the
> > basic framework is getting close to final at this point I believe. I'll
> > keep scanning the tests looking for other types of assertions that I've
> not
> > yet covered, but it's getting pretty solid I think. Hopefully, there
> won't
> > need to be too many more lines of code needed to express the test logic
> as
> > I like how things are looking right now.
> >
> >
> >
> >
> > On Thu, Sep 28, 2017 at 8:02 AM, Jorge Bay Gondra <
> > jorgebaygon...@gmail.com> wrote:
> >
> >> Great progress! I like how you avoided using ids, even if it adds some
> >> complexity to the transformation required.
> >>
> >> The Python step definitions are still quite simple, I think it would be
> >> mostly the same on the rest of the languages.
> >>
> >> On Thu, Sep 28, 2017 at 1:45 PM, Stephen Mallette  >
> >> wrote:
> >>
> >> > Just another update on progress with the test suite. The language of
> the
> >> > .feature files is getting slightly more complex as I try to translate
> >> more
> >> > and more of our Java process suite tests into the language of the
> >> gherkin
> >> > files. You can see here where I've added the ability to include
> >> parameters:
> >> >
> >> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> >> > gremlin-test/features/filter/Has.feature#L33
> >> >
> >> > I also came up with a method of asserting edges (didn't want to rely
> on
> >> ids
> >> > as it makes the gherkin harder to read, plus i didn't want to assume
> >> > TinkerGraph identifiers in case these tests were every used with some
> >> other
> >> > graph database that didn't use longs):
> >> >
> >> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> >> > gremlin-test/features/map/Vertex.feature#L105-L111
> >> >
> >> > for all those additions (and others) the logic required by the GLV to
> >> > process these tests has stayed surprisingly simple:
> >> >
> >> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> >> > gremlin-python/src/main/jython/radish/feature_steps.py
> >> >
> >> > There's a fair bit of regex/string manipulation involved there, but
> it's
> >> > processing strings from the feature file so that's the nature of it I
> >> > suppose. I think I'm of the mind that I want to port all of the tests
> to
> >> > feature files, so I wrote this unit test to help validate that none
> were
> >> > missed:
> >> >
> >> > https://github.com/apache/tinkerpop/blob/TINKERPOP-1784/
> >> > gremlin-test/src/test/java/org/apache/tinkerpop/gremlin/
> >> > structure/FeatureCoverageTest.java
> >> >
> >> > I don't know that we have to get to 100% porting right away, but I
> think
> >> >

Re: [DISCUSS] bothE() on self-reference

2017-10-25 Thread Daniel Kuppitz 
IMO it should return the edge only once.

Cheers,
Daniel


On Wed, Oct 25, 2017 at 5:47 AM, Stephen Mallette 
wrote:

> The test suite doesn't seem to enforce behavior related to self-relating
> edges. TinkerGraph does this:
>
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.addV().as('a').addE('self').to('a')
> ==>e[1][0-self->0]
> gremlin> g.E()
> ==>e[1][0-self->0]
> gremlin> g.V().bothE().count()
> ==>2
>
> Should bothE() return 2 in this case or 1? I think that we've said in the
> past that g.E() is the same as g.V().outE() or g.V().inE(), but not
> necessarily g.V().bothE().  Thoughts?
>

[DISCUSS] bothE() on self-reference

2017-10-25 Thread Stephen Mallette 
The test suite doesn't seem to enforce behavior related to self-relating
edges. TinkerGraph does this:

gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().as('a').addE('self').to('a')
==>e[1][0-self->0]
gremlin> g.E()
==>e[1][0-self->0]
gremlin> g.V().bothE().count()
==>2

Should bothE() return 2 in this case or 1? I think that we've said in the
past that g.E() is the same as g.V().outE() or g.V().inE(), but not
necessarily g.V().bothE().  Thoughts?

Re: [DISCUSS] Binary serialization format

2017-10-25 Thread Jorge Bay Gondra 
I think there are inherent benefits into creating our own serialization
format, which can be based on existing conventions (like big endian format
for any numeric) but has the advantages of being minimally descriptive. For
complex composite types, we don't have to specify the meta properties that
are expected for a type, ie:

Vertex is currently serialized as:
{"@type": "g:Vertex, "@value": { "id": { /**/ }, "label": { /**/ },
properties: { /**/ }}}

As all vertices have an id, a label and properties, it can be described in
a binary format as 3 place holders:  (when id
finishes, the label starts and so on...)

Furthermore, in the case of the label as it's always a string the
serialization format doesn't have to include the meta-type information.
That way it can be only as descriptive as needed, keeping it very compact
and easy to read.

On Wed, Oct 25, 2017 at 2:17 PM, Stephen Mallette 
wrote:

> We might want to use TinkerPop 3.x to experiment with the "perfect"
> serialization format for some distant future TinkerPop 4.x. We haven't
> quite gotten it completely right with anything that we have thus far, but
> on the other hand I don't think we'd conceived of the manner in which we
> use IO today back at the start of TinkerPop 3.x. One of the bad things we
> have going on is the proliferation of types that comes from coring our
> serialization type system around Java. That would be hopefully something
> resolved more nicely in TinkerPop 4.x, but I don't think there's much we
> could do about it for 3.x - we're sorta stuck with supporting all the stuff
> we have now. I do think it's worth taking a look at existing serialization
> formats before building our own, like the one Marko mention in the link
> initially posted in this thread, Neo4j's Bolt protocol, etc.
>
>
>
>
> On Tue, Oct 24, 2017 at 3:37 PM, David Brown  wrote:
>
> > JSON is comfortable and easy, but something like this makes sense to
> > me. This idea could be easily extended to to request/response messages
> > as well. For example, the desired op ('eval', 'bytecode', 'close'
> > etc.) could be represented with a 4 bit group, etc. etc. This would
> > allow driver authors to do a lot of optimizations for better
> > performance. Python for instance, can use C extensions or Cython to
> > get huge performance gains working with binary data...
> >
> > On Tue, Oct 24, 2017 at 6:27 AM, Jorge Bay Gondra
> >  wrote:
> > > Hi,
> > > I wanted to bring up the possibility to include a specific (as in
> > > non-generic) serialization formal for Graph data. I didn't want to
> > > bump the last
> > > dev discussion on serialization formats
> > >  > d2d0146a571dc66f973c9ee9c5@%3Cdev.tinkerpop.apache.org%3E>
> > > (I'm
> > > late to the party :) ) as I wanted to dedicate a separate thread.
> > >
> > > GraphSON2 and GraphSON3 have some nice features (readable,
> extensibility,
> > > ...) but it has some disadvantages, mainly around verbosity and
> > > performance. About Gryo, I think the interoperability issues with Kryo
> > > outside the JVM have already been discussed.
> > >
> > > I'm proposing a binary serialization format that is specifically
> designed
> > > for the types we handle (+ room for extensibility), with a compact
> > payload
> > > and fast serialization.
> > >
> > > For example:
> > > a) GraphSON3: {"@type": "g:Int32","@value":1}
> > > byte length = 31
> > > b) GraphBinary:  (a byte representing the type and 4
> > bytes
> > > representing the value), in bytes: 0x01 0 0 0 0x2
> > > byte length = 5
> > >
> > > The serialization logic for each format is:
> > > a) GraphSON3: perform generic json serialization; navigate through
> object
> > > tree to read the type name; convert the string value to int32
> > > representation.
> > > b) GraphBinary: read first byte to get the type; move offset + 1;
> > convert 4
> > > bytes into a int32 representation.
> > >
> > > Any thoughts?
> > > Thanks,
> > > Jorge
> >
> >
> >
> > --
> > David M. Brown
> > R.A. CulturePlex Lab, Western University
> >
>

Re: Sqlg's description

2017-10-25 Thread pieter gmail 

Thanks,
Pieter

On 25/10/2017 14:26, Stephen Mallette wrote:

As there were no objections to making the change, I went ahead and
published - it may take a few minutes for the changes to propogate. Thanks

On Sun, Oct 22, 2017 at 12:35 PM, pieter gmail 
wrote:


Hi,

Can I request Sqlg's description on the homepage <
https://tinkerpop.apache.org/> to be changed.
Sqlg now supports more back-ends and changes are that it will support non
RDBMS but SQL databases in the future.

Can we change it to

"OLTP implementation on SQL databases."

Thanks
Pieter

Re: Sqlg's description

2017-10-25 Thread Stephen Mallette 
As there were no objections to making the change, I went ahead and
published - it may take a few minutes for the changes to propogate. Thanks

On Sun, Oct 22, 2017 at 12:35 PM, pieter gmail 
wrote:

> Hi,
>
> Can I request Sqlg's description on the homepage <
> https://tinkerpop.apache.org/> to be changed.
> Sqlg now supports more back-ends and changes are that it will support non
> RDBMS but SQL databases in the future.
>
> Can we change it to
>
> "OLTP implementation on SQL databases."
>
> Thanks
> Pieter
>

Re: [DISCUSS] Binary serialization format

2017-10-25 Thread Stephen Mallette 
We might want to use TinkerPop 3.x to experiment with the "perfect"
serialization format for some distant future TinkerPop 4.x. We haven't
quite gotten it completely right with anything that we have thus far, but
on the other hand I don't think we'd conceived of the manner in which we
use IO today back at the start of TinkerPop 3.x. One of the bad things we
have going on is the proliferation of types that comes from coring our
serialization type system around Java. That would be hopefully something
resolved more nicely in TinkerPop 4.x, but I don't think there's much we
could do about it for 3.x - we're sorta stuck with supporting all the stuff
we have now. I do think it's worth taking a look at existing serialization
formats before building our own, like the one Marko mention in the link
initially posted in this thread, Neo4j's Bolt protocol, etc.




On Tue, Oct 24, 2017 at 3:37 PM, David Brown  wrote:

> JSON is comfortable and easy, but something like this makes sense to
> me. This idea could be easily extended to to request/response messages
> as well. For example, the desired op ('eval', 'bytecode', 'close'
> etc.) could be represented with a 4 bit group, etc. etc. This would
> allow driver authors to do a lot of optimizations for better
> performance. Python for instance, can use C extensions or Cython to
> get huge performance gains working with binary data...
>
> On Tue, Oct 24, 2017 at 6:27 AM, Jorge Bay Gondra
>  wrote:
> > Hi,
> > I wanted to bring up the possibility to include a specific (as in
> > non-generic) serialization formal for Graph data. I didn't want to
> > bump the last
> > dev discussion on serialization formats
> >  d2d0146a571dc66f973c9ee9c5@%3Cdev.tinkerpop.apache.org%3E>
> > (I'm
> > late to the party :) ) as I wanted to dedicate a separate thread.
> >
> > GraphSON2 and GraphSON3 have some nice features (readable, extensibility,
> > ...) but it has some disadvantages, mainly around verbosity and
> > performance. About Gryo, I think the interoperability issues with Kryo
> > outside the JVM have already been discussed.
> >
> > I'm proposing a binary serialization format that is specifically designed
> > for the types we handle (+ room for extensibility), with a compact
> payload
> > and fast serialization.
> >
> > For example:
> > a) GraphSON3: {"@type": "g:Int32","@value":1}
> > byte length = 31
> > b) GraphBinary:  (a byte representing the type and 4
> bytes
> > representing the value), in bytes: 0x01 0 0 0 0x2
> > byte length = 5
> >
> > The serialization logic for each format is:
> > a) GraphSON3: perform generic json serialization; navigate through object
> > tree to read the type name; convert the string value to int32
> > representation.
> > b) GraphBinary: read first byte to get the type; move offset + 1;
> convert 4
> > bytes into a int32 representation.
> >
> > Any thoughts?
> > Thanks,
> > Jorge
>
>
>
> --
> David M. Brown
> R.A. CulturePlex Lab, Western University
>

[jira] [Closed] (TINKERPOP-1808) Add ability to get the consumer in LambdaSideEffectStep

2017-10-25 Thread stephen mallette (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1808.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.3.1
   3.2.7

This just meant adding a "getter" method. Seems we did that on other 
{{LambdaHolder}} instances,  so the precedence for doing this was already 
there. Added the getter to other lambda steps that didn't have it as well:

https://github.com/apache/tinkerpop/commit/c0a03ca0ac57997895b6f867e5df109433cc35a5

Committed/pushed via CTR as this was a pretty small change.

> Add ability to get the consumer in LambdaSideEffectStep
> ---
>
> Key: TINKERPOP-1808
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1808
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.6
>Reporter: Bryn Cooke
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.2.7, 3.3.1
>
>
> When lambda steps are used in a traversal it would be helpful to allow access 
> to the contained lambda so that it can be wrapped without fundamentally 
> changing the structure of the traversal.
> Obtaining the lambda means that a strategy may wrap the lambda to provide 
> extra security context, or event collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1808) Add ability to get the consumer in LambdaSideEffectStep

2017-10-25 Thread Bryn Cooke (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryn Cooke updated TINKERPOP-1808:
--
Description: 
When lambda steps are used in a traversal it would be helpful to allow access 
to the contained lambda so that it can be wrapped without fundamentally 
changing the structure of the traversal.

Obtaining the lambda means that a strategy may wrap the lambda to provide extra 
security context, or event collection.

  was:
When lambdas are used in a traversal it would be helpful to allow access to the 
contained lambda so that it can be wrapped without fundamentally changing the 
structure of the traversal.

Obtaining the lambda means that a strategy may wrap the lambda to provide extra 
security context, or event collection.


> Add ability to get the consumer in LambdaSideEffectStep
> ---
>
> Key: TINKERPOP-1808
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1808
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Reporter: Bryn Cooke
>Priority: Minor
>
> When lambda steps are used in a traversal it would be helpful to allow access 
> to the contained lambda so that it can be wrapped without fundamentally 
> changing the structure of the traversal.
> Obtaining the lambda means that a strategy may wrap the lambda to provide 
> extra security context, or event collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (TINKERPOP-1808) Add ability to get the consumer in LambdaSideEffectStep

2017-10-25 Thread Bryn Cooke (JIRA) 
Bryn Cooke created TINKERPOP-1808:
-

 Summary: Add ability to get the consumer in LambdaSideEffectStep
 Key: TINKERPOP-1808
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1808
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Reporter: Bryn Cooke
Priority: Minor


When lambdas are used in a traversal it would be helpful to allow access to the 
contained lambda so that it can be wrapped without fundamentally changing the 
structure of the traversal.

Obtaining the lambda means that a strategy may wrap the lambda to provide extra 
security context, or event collection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)