Re: [VOTE] Accepting the gremlint donation

[Dylan Millikin]

Been following this since I would eventually like to get gremlinbin back on
its feet. Vote +1

On Thu 18 Feb 2021 at 06:58,  wrote:

> VOTE +1
>
> -Ursprüngliche Nachricht-
> Von: Divij Vaidya 
> Gesendet: Donnerstag, 18. Februar 2021 05:52
> An: dev@tinkerpop.apache.org
> Betreff: Re: [VOTE] Accepting the gremlint donation
>
> Vote +1
>
> On Thu, Feb 18, 2021 at 2:23 AM Stephen Mallette 
> wrote:
>
> > This vote is mostly a formality at this point as we had
> > consensus[1][2] months ago on accepting the gremlint donation from
> Øyvind Sæbø and Arqdoc.
> > The Incubator IP Clearance form has been completed and can be found
> > here and I will add a link to this thread to it once we are done:
> >
> > https://incubator.apache.org/ip-clearance/tinkerpop-gremlint.html
> >
> > This VOTE is open for the next 72 hours closing February 20, 2021
> > 9:00pm ET.
> >
> > My VOTE is +1
> >
> > [1]
> >
> > https://lists.apache.org/thread.html/r5bc915ec5281b3678a62e0be91cb26e7
> > 089d8a23252b7a5efcac5023%40%3Cdev.tinkerpop.apache.org%3E
> > [2]
> >
> > https://lists.apache.org/thread.html/raaefce2315ce7c32a288faa0657a3981
> > 9481dc0aff632bdabe0b9b71%40%3Cdev.tinkerpop.apache.org%3E
> >
> --
> Divij Vaidya
>
>

Re: [VOTE] TinkerPop 3.3.3 Release

[Dylan Millikin]

 Tests with the php driver all pass here as well.

VOTE +1

On Thu, May 10, 2018 at 11:43 AM, Stephen Mallette 
wrote:

> bah...hate when stuff like that happens. i can update that manually i
> guess, but the zip artifacts are just going to have ship with that typo.
> thanks for pointing that out.
>
> On Thu, May 10, 2018 at 11:40 AM, Evgeniy Ignatiev <
> yevgeniy.ignat...@gmail.com> wrote:
>
>> Hello.
>>
>> Probably a typo - upgrade docs list 3.3.3 as a duplicate 3.3.2 version.
>> [image: Upgrade Docs Screenshot]
>>
>> Best regards,
>> Evgeniy Ignatiev
>> On 5/9/2018 12:44 AM, Stephen Mallette wrote:
>>
>>  Hello,
>>
>> We are happy to announce that TinkerPop 3.3.3 is ready for release.
>>
>> The release artifacts can be found at this location:
>> 
>> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.3/
>>  
>>
>> The source distribution is provided by:
>> apache-tinkerpop-3.3.3-src.zip
>>
>> Two binary distributions are provided for user convenience:
>> apache-tinkerpop-gremlin-console-3.3.3-bin.zip
>> apache-tinkerpop-gremlin-server-3.3.3-bin.zip
>>
>> The GPG key used to sign the release artifacts is available at:
>> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>>
>> The online docs can be found here:
>> 
>> http://tinkerpop.apache.org/docs/3.3.3/
>>   (user docs)
>> 
>> http://tinkerpop.apache.org/docs/3.3.3/upgrade/
>>   (upgrade docs)
>> 
>> http://tinkerpop.apache.org/javadocs/3.3.3/core/
>>   (core javadoc)
>> 
>> http://tinkerpop.apache.org/javadocs/3.3.3/full/
>>   (full javadoc)
>>
>> The tag in Apache Git can be found here:
>> 
>> *https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=696f5e40e5c56c58a4ab703608a790d8130ea640
>>  
>> *
>>
>> The release notes are available here (i linked to the branch - github
>> hasn't sync'd the tag yet for some reason - not sure what the delay is with
>> Apache infra):
>> https://github.com/apache/tinkerpop/blob/tp33/CHANGELOG.
>> asciidoc#release-3-3-
>>  
>> 
>> 3
>>
>> The [VOTE] will be open for the next 72 hours --- closing Friday, May 11,
>> 2018 at 5:00pm EST.
>>
>> My vote is +1.
>>
>> Thank you very much,
>> Stephen
>>
>>
>>
>>
>

Re: [VOTE] TinkerPop 3.2.9 Release

[Dylan Millikin]

Tests with the php driver all pass. No regressions or anything noticeable.

VOTE +1



On Thu, May 10, 2018 at 10:48 AM, Daniel Kuppitz  wrote:

> VOTE: +1
>
> On Wed, May 9, 2018 at 10:15 AM, Ted Wilmes  wrote:
>
> > Docs and validate looked good +1
> >
> > Thanks,
> > Ted
> >
> > On Wed, May 9, 2018 at 6:26 AM, Stephen Mallette 
> > wrote:
> >
> > > VOTE +1 - reviewed published docs a bit and validate-distribution.sh is
> > > good
> > >
> > > On Tue, May 8, 2018 at 4:43 PM, Robert Dale  wrote:
> > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.2.9 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.9/
> > > >
> > > > The source distribution is provided by:
> > > > apache-tinkerpop-3.2.9-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > > apache-tinkerpop-gremlin-console-3.2.9-bin.zip
> > > > apache-tinkerpop-gremlin-server-3.2.9-bin.zip
> > > >
> > > > The GPG key used to sign the release artifacts is available at:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> > > >
> > > > The online docs can be found here:
> > > > http://tinkerpop.apache.org/docs/3.2.9/ (user docs)
> > > > http://tinkerpop.apache.org/docs/3.2.9/upgrade/ (upgrade
> docs)
> > > > http://tinkerpop.apache.org/javadocs/3.2.9/core/ (core
> > javadoc)
> > > > http://tinkerpop.apache.org/javadocs/3.2.9/full/ (full
> > javadoc)
> > > >
> > > > The tag in Apache Git can be found here:
> > > >
> > > > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > > > 721fd3c32d0a02337f156ef8d99e7ffb9f1cdc98
> > > >
> > > > The release notes are available here:
> > > >
> > > > https://github.com/apache/tinkerpop/blob/3.2.9/
> > > > CHANGELOG.asciidoc#release-3-2-9
> > > >
> > > > The [VOTE] will be open for the next 72 hours --- closing Friday (May
> > 11
> > > > 2018) at 17:00 EDT.
> > > >
> > > > My vote is +1.
> > > >
> > > > Thank you very much,
> > > > Robert Dale
> > > >
> > >
> >
>

Re: GRAPHSON 3.0 serializing, IO Ref, and parent map exception

[Dylan Millikin]

It makes sense that we shouldn't carry it forward. That wasn't what I was
getting to though. My initial plea was that since moving from GraphSON 1.0
to 3.0 can introduce some breaking changes I was asking if this should be
documented somewhere (update notes for example).
I've since decided against it, because this really only affects non-java
users (who typically would not be aware of the underlying IO but would be
affected by the changes) and depending on the driver's implementation it
may or may not be breaking. So it should be up to the "client" to report
the breaking change, not TP.

Right now since the php driver still needs to support the 3.2.x line, I've
opted to deserialize into the old ugly format. I'll introduce a breaking
change later.






On Mon, Apr 16, 2018 at 7:36 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> the "1" is no longer a thing (i.e. the toString() of a complex object)
> because GraphSON 3.0 allows complex keys. That "1" was a hack in prior
> versions of GraphSON to get around that problem. We shouldn't be trying to
> carry that forward. Does that make sense?
>
> On Mon, Apr 16, 2018 at 4:17 PM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
> > Actually, let me change that up a bit. I would expect the Map to be part
> of
> > Tree, not encapsulate it. So something like :
> >
> > "data":{
> >"@type":"g:List",
> >"@value":[{
> >   "@type":"g:Tree",
> >   "@value":[{
> > "@type":"g:Map",
> > "@value":{
> >"1",
> >{
> >   "key":{
> >  "@type":"g:Vertex",
> >  "@value":{
> > "id":{"@type":"g:Int64","@value":1},
> > "label":"vertex",
> > "properties":{"name": ...
> >
> > It could be debated that this is something the client side serializer
> > could/would need to add in when treating Tree. But still a little
> lopsided.
> >
> > BTW if you're wondering, the "1" key from GRAPHSON 1.0 is a string
> > representation of the *element id*. So I really wouldn't be surprised if
> > people were using that information currently.
> >
> >
> > On Mon, Apr 16, 2018 at 4:04 PM, Dylan Millikin <
> dylan.milli...@gmail.com>
> > wrote:
> >
> > > I'm going to leverage this email a bit more for the following point.
> > >
> > > I noticed that the actual format of Tree has changed with GRAPHSON 3.0.
> > > We're now handling Lists whereas it used to be Maps. This seems to be a
> > > breaking change when using GRAPHSON 3.0.
> > >
> > > Given: g.V(1).out().properties("name").tree()
> > >
> > > In 1.0 we get :
> > >
> > > "data":[{
> > >"1":{
> > >   "key":{
> > >  "id":1,
> > >  "label":"vertex",
> > >  "type":"vertex",
> > >  "properties":{"name": ...
> > >
> > > In 3.0 we get :
> > >
> > > "data":{
> > >"@type":"g:List",
> > >"@value":[{
> > >   "@type":"g:Tree",
> > >   "@value":[{
> > >  "key":{
> > >  "@type":"g:Vertex",
> > >  "@value":{
> > >  "id":{"@type":"g:Int64","@value":1},
> > >  "label":"vertex",
> > >  "properties":{"name": ...
> > >
> > > When instead we should be getting :
> > >
> > > "data":{
> > >"@type":"g:Map",
> > >"@value":[{
> > >   "1",
> > >   {
> > >  "@type":"g:Tree",
> > >  "@value":[{
> > > "key":{
> > >"@type":"g:Vertex",
> > >"@value":{
> > >"id":{"@type":"g:Int64","@value":1},
> > >"

Re: GRAPHSON 3.0 serializing, IO Ref, and parent map exception

[Dylan Millikin]

Actually, let me change that up a bit. I would expect the Map to be part of
Tree, not encapsulate it. So something like :

"data":{
   "@type":"g:List",
   "@value":[{
  "@type":"g:Tree",
  "@value":[{
"@type":"g:Map",
"@value":{
   "1",
   {
  "key":{
 "@type":"g:Vertex",
 "@value":{
"id":{"@type":"g:Int64","@value":1},
"label":"vertex",
"properties":{"name": ...

It could be debated that this is something the client side serializer
could/would need to add in when treating Tree. But still a little lopsided.

BTW if you're wondering, the "1" key from GRAPHSON 1.0 is a string
representation of the *element id*. So I really wouldn't be surprised if
people were using that information currently.


On Mon, Apr 16, 2018 at 4:04 PM, Dylan Millikin <dylan.milli...@gmail.com>
wrote:

> I'm going to leverage this email a bit more for the following point.
>
> I noticed that the actual format of Tree has changed with GRAPHSON 3.0.
> We're now handling Lists whereas it used to be Maps. This seems to be a
> breaking change when using GRAPHSON 3.0.
>
> Given: g.V(1).out().properties("name").tree()
>
> In 1.0 we get :
>
> "data":[{
>"1":{
>   "key":{
>  "id":1,
>  "label":"vertex",
>  "type":"vertex",
>  "properties":{"name": ...
>
> In 3.0 we get :
>
> "data":{
>"@type":"g:List",
>"@value":[{
>   "@type":"g:Tree",
>   "@value":[{
>  "key":{
>  "@type":"g:Vertex",
>  "@value":{
>  "id":{"@type":"g:Int64","@value":1},
>  "label":"vertex",
>  "properties":{"name": ...
>
> When instead we should be getting :
>
> "data":{
>"@type":"g:Map",
>"@value":[{
>   "1",
>   {
>  "@type":"g:Tree",
>  "@value":[{
> "key":{
>"@type":"g:Vertex",
>"@value":{
>"id":{"@type":"g:Int64","@value":1},
>"label":"vertex",
>"properties":{"name": ...
>
> I like the new way better to be honest. And it's probably more consistent
> with gryo, but this is a breaking change and inconsistent across
> serializing methods ATM. At the very least we should add it to the upgrade
> information and perhaps consider aligning GRAPHSON 1.0 with this for 3.4
>
> Let me know if you guys think it deserves a thread of it's own. I just
> didn't want to pollute the list too much while I fiddle around.
>
> On Mon, Apr 16, 2018 at 11:27 AM, Dylan Millikin <dylan.milli...@gmail.com
> > wrote:
>
>> Ok that makes a lot of sense. I’ll change the the way the driver operates
>> to reflect that and I’ll just have the RequestMessage serialize down to a
>> native json map.
>>
>> Cheers!
>>
>> On Mon 16 Apr 2018 at 07:36, Stephen Mallette <spmalle...@gmail.com>
>> wrote:
>>
>>> The IO examples show that it works as you say:
>>>
>>> http://tinkerpop.apache.org/docs/current/dev/io/#_requestmessage_3
>>>
>>> I'd agree that it isn't really consistent though the "type" really isn't
>>> a
>>> g:Map i don't think - it's really a RequestMessage, but we don't have a
>>> specific type for that. Gremlin Server just understands it that way.
>>>
>>>
>>>
>>> On Mon, Apr 16, 2018 at 1:51 AM, Dylan Millikin <dm...@apache.org>
>>> wrote:
>>>
>>> >  Hey guys,
>>> >
>>> > Just been working on implementing GRAPHSON 3.0 into the php world.
>>> (testing
>>> > against gremlin-server 3.3.2)
>>> >
>>> > I noticed that the following request message fails:
>>> >
>>> > {
>>> >"@type":"g:Map",
>>> >"@value&q

Re: GRAPHSON 3.0 serializing, IO Ref, and parent map exception

[Dylan Millikin]

I'm going to leverage this email a bit more for the following point.

I noticed that the actual format of Tree has changed with GRAPHSON 3.0.
We're now handling Lists whereas it used to be Maps. This seems to be a
breaking change when using GRAPHSON 3.0.

Given: g.V(1).out().properties("name").tree()

In 1.0 we get :

"data":[{
   "1":{
  "key":{
 "id":1,
 "label":"vertex",
 "type":"vertex",
 "properties":{"name": ...

In 3.0 we get :

"data":{
   "@type":"g:List",
   "@value":[{
  "@type":"g:Tree",
  "@value":[{
 "key":{
 "@type":"g:Vertex",
 "@value":{
 "id":{"@type":"g:Int64","@value":1},
 "label":"vertex",
 "properties":{"name": ...

When instead we should be getting :

"data":{
   "@type":"g:Map",
   "@value":[{
  "1",
  {
 "@type":"g:Tree",
 "@value":[{
"key":{
   "@type":"g:Vertex",
   "@value":{
   "id":{"@type":"g:Int64","@value":1},
   "label":"vertex",
   "properties":{"name": ...

I like the new way better to be honest. And it's probably more consistent
with gryo, but this is a breaking change and inconsistent across
serializing methods ATM. At the very least we should add it to the upgrade
information and perhaps consider aligning GRAPHSON 1.0 with this for 3.4

Let me know if you guys think it deserves a thread of it's own. I just
didn't want to pollute the list too much while I fiddle around.

On Mon, Apr 16, 2018 at 11:27 AM, Dylan Millikin <dylan.milli...@gmail.com>
wrote:

> Ok that makes a lot of sense. I’ll change the the way the driver operates
> to reflect that and I’ll just have the RequestMessage serialize down to a
> native json map.
>
> Cheers!
>
> On Mon 16 Apr 2018 at 07:36, Stephen Mallette <spmalle...@gmail.com>
> wrote:
>
>> The IO examples show that it works as you say:
>>
>> http://tinkerpop.apache.org/docs/current/dev/io/#_requestmessage_3
>>
>> I'd agree that it isn't really consistent though the "type" really isn't a
>> g:Map i don't think - it's really a RequestMessage, but we don't have a
>> specific type for that. Gremlin Server just understands it that way.
>>
>>
>>
>> On Mon, Apr 16, 2018 at 1:51 AM, Dylan Millikin <dm...@apache.org> wrote:
>>
>> >  Hey guys,
>> >
>> > Just been working on implementing GRAPHSON 3.0 into the php world.
>> (testing
>> > against gremlin-server 3.3.2)
>> >
>> > I noticed that the following request message fails:
>> >
>> > {
>> >"@type":"g:Map",
>> >"@value":[
>> >   "requestId","f990037e-3b55-49a4-a108-2f0e8c162715",
>> >   "processor","",
>> >   "op","eval",
>> >   "args",{"@type":"g:Map","@value":["gremlin","5+5"]}
>> >]
>> > }
>> >
>> > While this one doesn't:
>> >
>> > {
>> >"requestId":"bf26426b-ba27-475f-aafa-527ce0b0116c",
>> >"processor":"",
>> >"op":"eval",
>> >"args":{"@type":"g:Map","@value":["gremlin","5+5"]}
>> >}
>> > }
>> >
>> > Seems like the parent map should not be serialized using GRAPHSON 3.0
>> > standards. This isn't readily apparent because going through the code I
>> > noticed both gremlin-javascript and gremlin-python seem to simply fall
>> back
>> > to JSON natives for this task and don't define the map type? PHP is very
>> > much the same and I could fall back to JSON natives, but is this an
>> > oversight? You would expect the entire "message" portion of the
>> > Websocket RequestMessage
>> > to be serialized by the same standard.
>> >
>> > I've overall done a decent job of staying up to date with the mailing
>> list
>> > (even though I haven't participated) but I may have overlooked this
>> already
>> > being discussed. If anyone has a tldr regarding this that would be
>> great?
>> >
>> > Thanks!
>> >
>> > FYI : error message for the first one, it seems to choke on the @value
>> > List.
>> >
>> > [WARN] AbstractGraphSONMessageSerializerV2d0 - Request
>> > [PooledUnsafeDirectByteBuf(ridx: 158, widx: 158, cap: 175)] could not
>> be
>> > deserialized by org.apache.tinkerpop.gremlin.driver.ser.
>> > AbstractGraphSONMessageSerializerV2d0.
>> > org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException:
>> Could
>> > not deserialize the JSON value as required. Nested exception:
>> > java.lang.InstantiationException:
>> > Cannot deserialize the value with the detected type contained in the
>> JSON
>> > ('g:Map') to the type specified in parameter to the object mapper (class
>> > org.apache.tinkerpop.gremlin.driver.message.RequestMessage). Those
>> types
>> > are incompatible.
>> >  at [Source: (byte[])"{"@type":"g:Map","@value":["requestId","f990037e-
>> > 3b55-49a4-a108-2f0e8c162715","processor","","op","eval","
>> > args",{"@type":"g:Map","@value":["gremlin","5+5"]}]}"; line: 1, column:
>> > 27]
>> >
>>
>

Re: GRAPHSON 3.0 serializing, IO Ref, and parent map exception

[Dylan Millikin]

Ok that makes a lot of sense. I’ll change the the way the driver operates
to reflect that and I’ll just have the RequestMessage serialize down to a
native json map.

Cheers!

On Mon 16 Apr 2018 at 07:36, Stephen Mallette <spmalle...@gmail.com> wrote:

> The IO examples show that it works as you say:
>
> http://tinkerpop.apache.org/docs/current/dev/io/#_requestmessage_3
>
> I'd agree that it isn't really consistent though the "type" really isn't a
> g:Map i don't think - it's really a RequestMessage, but we don't have a
> specific type for that. Gremlin Server just understands it that way.
>
>
>
> On Mon, Apr 16, 2018 at 1:51 AM, Dylan Millikin <dm...@apache.org> wrote:
>
> >  Hey guys,
> >
> > Just been working on implementing GRAPHSON 3.0 into the php world.
> (testing
> > against gremlin-server 3.3.2)
> >
> > I noticed that the following request message fails:
> >
> > {
> >"@type":"g:Map",
> >"@value":[
> >   "requestId","f990037e-3b55-49a4-a108-2f0e8c162715",
> >   "processor","",
> >   "op","eval",
> >   "args",{"@type":"g:Map","@value":["gremlin","5+5"]}
> >]
> > }
> >
> > While this one doesn't:
> >
> > {
> >"requestId":"bf26426b-ba27-475f-aafa-527ce0b0116c",
> >"processor":"",
> >"op":"eval",
> >"args":{"@type":"g:Map","@value":["gremlin","5+5"]}
> >}
> > }
> >
> > Seems like the parent map should not be serialized using GRAPHSON 3.0
> > standards. This isn't readily apparent because going through the code I
> > noticed both gremlin-javascript and gremlin-python seem to simply fall
> back
> > to JSON natives for this task and don't define the map type? PHP is very
> > much the same and I could fall back to JSON natives, but is this an
> > oversight? You would expect the entire "message" portion of the
> > Websocket RequestMessage
> > to be serialized by the same standard.
> >
> > I've overall done a decent job of staying up to date with the mailing
> list
> > (even though I haven't participated) but I may have overlooked this
> already
> > being discussed. If anyone has a tldr regarding this that would be great?
> >
> > Thanks!
> >
> > FYI : error message for the first one, it seems to choke on the @value
> > List.
> >
> > [WARN] AbstractGraphSONMessageSerializerV2d0 - Request
> > [PooledUnsafeDirectByteBuf(ridx: 158, widx: 158, cap: 175)] could not be
> > deserialized by org.apache.tinkerpop.gremlin.driver.ser.
> > AbstractGraphSONMessageSerializerV2d0.
> > org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could
> > not deserialize the JSON value as required. Nested exception:
> > java.lang.InstantiationException:
> > Cannot deserialize the value with the detected type contained in the JSON
> > ('g:Map') to the type specified in parameter to the object mapper (class
> > org.apache.tinkerpop.gremlin.driver.message.RequestMessage). Those types
> > are incompatible.
> >  at [Source: (byte[])"{"@type":"g:Map","@value":["requestId","f990037e-
> > 3b55-49a4-a108-2f0e8c162715","processor","","op","eval","
> > args",{"@type":"g:Map","@value":["gremlin","5+5"]}]}"; line: 1, column:
> > 27]
> >
>

GRAPHSON 3.0 serializing, IO Ref, and parent map exception

[Dylan Millikin]

 Hey guys,

Just been working on implementing GRAPHSON 3.0 into the php world. (testing
against gremlin-server 3.3.2)

I noticed that the following request message fails:

{
   "@type":"g:Map",
   "@value":[
  "requestId","f990037e-3b55-49a4-a108-2f0e8c162715",
  "processor","",
  "op","eval",
  "args",{"@type":"g:Map","@value":["gremlin","5+5"]}
   ]
}

While this one doesn't:

{
   "requestId":"bf26426b-ba27-475f-aafa-527ce0b0116c",
   "processor":"",
   "op":"eval",
   "args":{"@type":"g:Map","@value":["gremlin","5+5"]}
   }
}

Seems like the parent map should not be serialized using GRAPHSON 3.0
standards. This isn't readily apparent because going through the code I
noticed both gremlin-javascript and gremlin-python seem to simply fall back
to JSON natives for this task and don't define the map type? PHP is very
much the same and I could fall back to JSON natives, but is this an
oversight? You would expect the entire "message" portion of the
Websocket RequestMessage
to be serialized by the same standard.

I've overall done a decent job of staying up to date with the mailing list
(even though I haven't participated) but I may have overlooked this already
being discussed. If anyone has a tldr regarding this that would be great?

Thanks!

FYI : error message for the first one, it seems to choke on the @value
List.

[WARN] AbstractGraphSONMessageSerializerV2d0 - Request
[PooledUnsafeDirectByteBuf(ridx: 158, widx: 158, cap: 175)] could not be
deserialized by org.apache.tinkerpop.gremlin.driver.ser.
AbstractGraphSONMessageSerializerV2d0.
org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could
not deserialize the JSON value as required. Nested exception:
java.lang.InstantiationException:
Cannot deserialize the value with the detected type contained in the JSON
('g:Map') to the type specified in parameter to the object mapper (class
org.apache.tinkerpop.gremlin.driver.message.RequestMessage). Those types
are incompatible.
 at [Source: (byte[])"{"@type":"g:Map","@value":["requestId","f990037e-
3b55-49a4-a108-2f0e8c162715","processor","","op","eval","
args",{"@type":"g:Map","@value":["gremlin","5+5"]}]}"; line: 1, column: 27]

Re: [VOTE] TinkerPop 3.3.2 Release

[Dylan Millikin]

Ran all tests from the php end. Everything passes. Actually added a couple
more and those also pass.

VOTE: +1

On Fri, Apr 6, 2018 at 9:29 AM, Jason Plurad  wrote:

> Validated the binaries, did several manual tests with the Gremlin Server +
> Gremlin Console, looked over the documentation.
>
> The instructions on the download page to verify with gpg manually are fine
> since the output does say "Good signature" even with the [unknown] suffix.
>
> VOTE: +1
>
> On Wed, Apr 4, 2018 at 2:08 PM, Daniel Kuppitz  wrote:
>
> > With the suffix ignored it all looks good.
> >
> > Validating binary distributions
> >
> > * downloading Apache TinkerPop Gremlin
> > (apache-tinkerpop-gremlin-console-3.3.2-bin.zip)... OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 checksum ... OK
> > * unzipping Apache TinkerPop Gremlin ... OK
> > * validating Apache TinkerPop Gremlin's docs ... OK
> > * validating Apache TinkerPop Gremlin's binaries ... OK
> > * validating Apache TinkerPop Gremlin's legal files ...
> >   * LICENSE ... OK
> >   * NOTICE ... OK
> > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > * testing script evaluation ... OK
> >
> > * downloading Apache TinkerPop Gremlin
> > (apache-tinkerpop-gremlin-server-3.3.2-bin.zip)... OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 checksum ... OK
> > * unzipping Apache TinkerPop Gremlin ... OK
> > * validating Apache TinkerPop Gremlin's docs ... OK
> > * validating Apache TinkerPop Gremlin's binaries ... OK
> > * validating Apache TinkerPop Gremlin's legal files ...
> >   * LICENSE ... OK
> >   * NOTICE ... OK
> > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > * validating Apache TinkerPop Gremlin's lib directory ... OK
> >
> > Validating source distribution
> >
> > * downloading Apache TinkerPop 3.3.2 (apache-tinkerpop-3.3.2-src.zip)...
> > OK
> > * validating signatures and checksums ...
> >   * PGP signature ... OK
> >   * MD5 checksum ... OK
> >   * SHA1 checksum ... OK
> > * unzipping Apache TinkerPop 3.3.2 ... OK
> > * building project ... OK
> >
> >
> > VOTE: +1 (if nobody has any objections regarding the suffix)
> >
> > Furthermore, here's the output of the verification step shown on the
> > download page:
> >
> > $ gpg --verify apache-tinkerpop-3.3.2-src.zip.asc
> > apache-tinkerpop-3.3.2-src.zip
> > gpg: Signature made Tue 03 Apr 2018 12:45:53 PM MST
> > gpg:using RSA key EA53A99854EAB0E6
> > gpg: Good signature from "Stephen Mallette "
> > [unknown]
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg:  There is no indication that the signature belongs to the
> > owner.
> > Primary key fingerprint: 0871 A360 AAB5 FD42 2516  E2FB EA53 A998 54EA
> B0E6
> >
> >
> > Cheers,
> > Daniel
> >
> >
> > On Wed, Apr 4, 2018 at 1:59 PM, Daniel Kuppitz  wrote:
> >
> > > Much newer.
> > >
> > > $ gpg --version
> > > gpg (GnuPG) 2.1.15
> > > libgcrypt 1.7.8
> > > Copyright (C) 2016 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <
> https://gnu.org/licenses/gpl
> > .
> > > html>
> > > This is free software: you are free to change and redistribute it.
> > > There is NO WARRANTY, to the extent permitted by law.
> > >
> > > Home: /home/daniel/.gnupg
> > > Supported algorithms:
> > > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> > > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> > > CAMELLIA128, CAMELLIA192, CAMELLIA256
> > > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> > > Compression: Uncompressed, ZIP, ZLIB, BZIP2
> > >
> > >
> > >
> > > On Wed, Apr 4, 2018 at 1:57 PM, Stephen Mallette  >
> > > wrote:
> > >
> > >> out of curiosity - what gpg version do you have? i'm on:
> > >>
> > >> $ gpg --version
> > >> gpg (GnuPG) 1.4.16
> > >>
> > >> is that ancient or something? i'd be curious if anyone else has this
> > >> problem. it's also semi-concerning that this doesn't work because we'd
> > >> want
> > >> to the verification to behave right with the instructions we have
> here:
> > >>
> > >> http://tinkerpop.apache.org/downloads.html
> > >>
> > >> wonder if that's a problem too?
> > >>
> > >>
> > >>
> > >> On Wed, Apr 4, 2018 at 4:54 PM, Daniel Kuppitz 
> wrote:
> > >>
> > >> > Either this or I might have a newer gpg version which changed the
> > output
> > >> > slightly. We already ignore the suffix for Ted and Jason, so I guess
> > we
> > >> > should just use the same pattern for everyone. I can CTR this change
> > >> into
> > >> > all main branches; it's just that:
> > >> >
> > >> > -[ `gpg ${ZIP_FILENAME}.asc 2>&1 | grep -c '^gpg: Good signature
> from
> > >> > "Stephen Mallette 

Re: [TinkerPop] Re: GremlinBin (beta) is here. An online Gremlin "fiddle"

[Dylan Millikin]

Hey guys,

Sorry I've been so absent over the past year I've been having a lot of
personal issues. But I've been keeping a bit of an eye on things regardless
and plan on making a proper comeback to bring everything up to speed.
I noticed JB had a few docker images going so I might use those to allow
for different TP versions and remove sandboxing on gremlinbin.


Anyways, thanks for bringing this up by mail. It appears that I haven't
gotten any of the github notifications for that repo seeing as there are
some significantly old issues in there.

I've done the necessary corrections and things should be working again.

Cheers.

On Fri, Jun 30, 2017 at 7:53 AM, Robert Dale  wrote:

> I recommend clicking on 'Issues' which will take you to this link
> https://github.com/PommeVerte/gremlin-bin/issues
>
> Robert Dale
>
> On Fri, Jun 30, 2017 at 3:08 AM, Raj  wrote:
>
>> I was trying to use gremlinbin but it was either not running my commands
>> or if it did then was showing stackoverflow error.
>>
>> On Thursday, 17 March 2016 00:03:18 UTC+5:30, Dmill wrote:
>>>
>>> Hey guys,
>>>
>>> I wanted to announce that www.gremlinbin.com is prime for beta.
>>>
>>> GremlinBin is essentially an online console/sandbox for you to test run
>>> your Gremlin queries, then save them and share them with other users via
>>> links. Think of it as a jsFiddle or pasteBin for Gremlin.
>>>
>>> It's still in it's early stages so there is no mobile support and there
>>> are annoyingly verbose errors (if you encounter any; to help with reporting
>>> to github). Both of these will go with future updates.
>>>
>>> I will however guaranty that the links to your "bins" will not break
>>> with future updates so feel free to use them in blogs/emails/etc.
>>> Here's one to give you an idea : http://www.gremlinbin.com/bi
>>> n/view/56e9a41538639
>>>
>>> Let me know what you think. And feel free to open issues on github if
>>> you have any feature requests (or are encountering glitches).
>>>
>>> Big thanks goes to JB Musso for his work on the js driver, Stephen for
>>> putting up with me and the others for their valuable feedback.
>>>
>>> Cheers.
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Gremlin-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to gremlin-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/gremlin-users/a1597eff-aa21-4eaf-8d69-a4c81c38931c%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/gremlin-users/CABed_4qMCfEPy5m3nYSn%2Bmdi8Bz5MqU0FFZMSSKheRgZnpv_
> YQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

Re: [VOTE] TinkerPop 3.1.6 Release

[Dylan Millikin]

I ran the php driver tests against this locally and everything is good.

VOTE +1 from me!!

Cheers.

On Mon, Feb 6, 2017 at 7:48 AM, Stephen Mallette 
wrote:

> I can't remember the error I got, but I think it makes sense to test
> validate-distribution.sh from the branch that the release was generated
> from. I probably shouldn't have tried to test from master - that sorta
> doesn't make sense.
>
> On Sun, Feb 5, 2017 at 7:58 AM, Daniel Kuppitz  wrote:
>
> > >
> > > Note that I couldn't use the validate-distribution.sh on master for
> some
> > reason
> > > - it failed
> >
> >
> > Did it fail when it tested gremlin.sh -e..? This test was added recently
> > and I think that's expected to fail in 3.1.x. All others should succeed
> > though, but in general we should always use the validation script from
> the
> > respective development branches (tp31/, tp32/  and master/).
> >
> > Validation worked for me too, hence ...
> >
> > VOTE: +1
> >
> > Cheers,
> > Daniel
> >
> >
> > On Sat, Feb 4, 2017 at 2:20 AM, Stephen Mallette 
> > wrote:
> >
> > > Hey Ted - You're a little early as we agreed a while back to let two
> > > weekends pass from code freeze to VOTE day (maybe release docs need to
> be
> > > updated to reflect that). Not a big deal imo as I doubt there are many
> > > folks still testing on 3.1.6 at this point, so I'm fine to VOTE from
> here
> > > if everyone else is. If anyone feels like we need to extend the VOTEing
> > > time, just yell.  3.2.4 voting definitely shouldn't start until Monday.
> > >
> > > In the mean time, as it is right now:
> > >
> > > $ bin/validate-distribution.sh 3.1.6
> > >
> > > Validating binary distributions
> > >
> > > * downloading Apache TinkerPop Gremlin
> > > (apache-tinkerpop-gremlin-console-3.1.6-bin.zip)... OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * MD5 checksum ... OK
> > >   * SHA1 checksum ... OK
> > > * unzipping Apache TinkerPop Gremlin ... OK
> > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > * validating Apache TinkerPop Gremlin's legal files ...
> > >   * LICENSE ... OK
> > >   * NOTICE ... OK
> > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > > * testing script evaluation ... OK
> > >
> > > * downloading Apache TinkerPop Gremlin
> > > (apache-tinkerpop-gremlin-server-3.1.6-bin.zip)... OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * MD5 checksum ... OK
> > >   * SHA1 checksum ... OK
> > > * unzipping Apache TinkerPop Gremlin ... OK
> > > * validating Apache TinkerPop Gremlin's docs ... OK
> > > * validating Apache TinkerPop Gremlin's binaries ... OK
> > > * validating Apache TinkerPop Gremlin's legal files ...
> > >   * LICENSE ... OK
> > >   * NOTICE ... OK
> > > * validating Apache TinkerPop Gremlin's plugin directory ... OK
> > > * validating Apache TinkerPop Gremlin's lib directory ... OK
> > >
> > > Validating source distribution
> > >
> > > * downloading Apache TinkerPop 3.1.6 (apache-tinkerpop-3.1.6-src.
> zip)...
> > > OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * MD5 checksum ... OK
> > >   * SHA1 checksum ... OK
> > > * unzipping Apache TinkerPop 3.1.6 ... OK
> > > * building project ... OK
> > >
> > > Note that I couldn't use the validate-distribution.sh on master for
> some
> > > reason - it failed - had to use the one in tp31 and the above was my
> > output
> > > so I think all is good: Thanks for handling the release Ted - that's a
> > big
> > > help to me and the community.
> > >
> > > VOTE +1
> > >
> > >
> > >
> > >
> > >
> > > On Feb 3, 2017 6:09 PM, "Ted Wilmes"  wrote:
> > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.1.6 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.6/
> > > >
> > > > The source distribution is provided by:
> > > > apache-tinkerpop-3.1.6-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > > apache-tinkerpop-gremlin-console-3.1.6-bin.zip
> > > > apache-tinkerpop-gremlin-server-3.1.6-bin.zip
> > > >
> > > > The GPG key used to sign the release artifacts is available at:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> > > >
> > > > The online docs can be found here:
> > > > http://tinkerpop.apache.org/docs/3.1.6/ (user docs)
> > > > http://tinkerpop.apache.org/docs/3.1.6/upgrade/ (upgrade
> docs)
> > > > http://tinkerpop.apache.org/javadocs/3.1.6/core/ (core
> > javadoc)
> > > > http://tinkerpop.apache.org/javadocs/3.1.6/full/ (full
> > javadoc)
> > > >
> > > > The tag in Apache Git can be found 

Re: state of git

[Dylan Millikin]

With multiple branches set up as they are here, wouldn't it help to move to
a more classical workflow, that is to push to master and then
backport/cherry pick downwards? This comes with it's own set of
implications but thought I would ask.

On Thu, Nov 3, 2016 at 9:19 PM, Stephen Mallette 
wrote:

> ...and all is right with the world again...
>
> In case others are interested, the trouble here is that if I had merged my
> tp32 to master with my change from tp31, then I would have brought Marko's
> changes from tp32 to master. I wouldn't want to do that because I wouldn't
> have been sure that Marko wanted that to happen. For all I knew he could
> have been trying to fix a problem on master with his merge from tp32 and my
> merging could have broken the branch. Ideally, you should only push your
> own changes, so if you ever merge tp32 to master (for example) and there
> are commits present that are not ones you did, you probably need to stop
> and figure out what's going on.
>
> Here's how I noticed it:
>
> $ git checkout master
> Switched to branch 'master'
> $ git merge tp32
> Auto-merging CHANGELOG.asciidoc
> Merge made by the 'recursive' strategy.
>  CHANGELOG.asciidoc
>  |  2 ++
>  docs/src/dev/provider/index.asciidoc
>  |  2 +-
>  docs/src/upgrade/release-3.1.x-incubating.asciidoc
>  | 18
> ++
>  gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/
> process/traversal/strategy/decoration/SubgraphStrategy.java
> | 16 +++-
>  gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/
> process/traversal/strategy/optimization/IncidentToAdjacentStrategy.java
> | 11 ++-
>  gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/
> process/traversal/util/TraversalHelper.java
> | 21 +
>  gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/
> driver/Connection.java
>|  2 +-
>  gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/
> server/op/session/SessionOpProcessor.java
> |  5 +
>  8 files changed, 61 insertions(+), 16 deletions(-)
>
> WHOA - I knew that I didn't touch SubgraphStrategy or
> IncidentToAdjacentStrategy, so that looked fishy. So I get rid of all that
> with:
>
> $ git reset --hard origin/master
> HEAD is now at ea085f8 Merge branch 'tp32'
>
> and reset my local master branch back to what it was prior to the merge
> (i.e what is at origin/master). After I emailed the list and ping'd marko
> who promptly did the merge to master I did:
>
> $ git fetch origin
> remote: Counting objects: 123, done.
> remote: Compressing objects: 100% (8/8), done.
> remote: Total 13 (delta 4), reused 0 (delta 0)
> Unpacking objects: 100% (13/13), done.
> From https://git-wip-us.apache.org/repos/asf/tinkerpop
>ea085f8..eaad5a9  master -> origin/master
> $ git rebase origin/master
> First, rewinding head to replay your work on top of it...
> Fast-forwarded master to origin/master.
> $ git merge tp32
> Auto-merging CHANGELOG.asciidoc
> Merge made by the 'recursive' strategy.
>  CHANGELOG.asciidoc
>  |  1 +
>  docs/src/dev/provider/index.asciidoc
>  |  2 +-
>  docs/src/upgrade/release-3.1.x-incubating.asciidoc
>  | 18 ++
>  gremlin-driver/src/main/java/org/apache/tinkerpop/gremlin/
> driver/Connection.java
>|  2 +-
>  gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/
> server/op/session/SessionOpProcessor.java
> |  5 +
>  5 files changed, 26 insertions(+), 2 deletions(-)
>
> So i applied marko's changes to master with git rebase, then merged my
> local tp32 to master and now those two changes I wasn't responsible for are
> gone. Then it's just a push doing master first and then tp32 (newest
> release to oldest release order):
>
> $ git push origin master
> Counting objects: 213, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (32/32), done.
> Writing objects: 100% (48/48), 3.44 KiB | 0 bytes/s, done.
> Total 48 (delta 25), reused 0 (delta 0)
> remote: tinkerpop git commit: Merge branch 'tp32'
> remote: tinkerpop git commit: Merge branch 'tp31' into tp32
> remote: tinkerpop git commit: TINKERPOP-1544 Return confirmation on session
> close
> gTo https://git-wip-us.apache.org/repos/asf/tinkerpop.git/
>eaad5a9..3f57dfe  master -> master
> $ git push origin tp32
> Total 0 (delta 0), reused 0 (delta 0)
> remote: tinkerpop git commit: Merge branch 'tp31' into tp32
> remote: tinkerpop git commit: TINKERPOP-1544 Return confirmation on session
> close
> To https://git-wip-us.apache.org/repos/asf/tinkerpop.git/
>b4d0ef9..9e284f7  tp32 -> tp32
>
> All good!
>
>
> On Thu, Nov 3, 2016 at 10:31 AM, Marko 

Re: [DISCUSS] ASF Board Draft Report - October 2016

[Dylan Millikin]

Yeah looking great!

On Tue, Oct 4, 2016 at 10:39 AM, Marko Rodriguez 
wrote:

> Diamn — that is one solid report.
>
> Marko.
>
> http://markorodriguez.com
>
>
>
> > On Oct 4, 2016, at 8:36 AM, Stephen Mallette 
> wrote:
> >
> > A lot of stuff seems to have happened since our last report - did I miss
> > anything?
> >
> > 
> --
> >
> > ## Description:
> > Apache TinkerPop is a graph computing framework for both graph databases
> > (OLTP) and graph analytic systems (OLAP).
> >
> > ## Activity:
> > TinkerPop has added a new member to the PMC in Jason Plurad and a new
> > committer in David Brown.
> >
> > TinkerPop released 3.1.4 and 3.2.2. 3.2.2 contains gremlin-python[1],
> > which
> > officially opens TinkerPop up to the Python community. We tend to think
> > of Python as the most used language for TinkerPop outside of the JVM so
> > having native support for it should help expand usage. October will see
> > releases 3.1.5 and 3.2.3. These two releases are mostly bug fixes and
> > minor
> > usability improvements. We expect to continue to maintain both of these
> > lines of code (bug fixes for 3.1.4 and ongoing development of 3.2.2), but
> > intend to begin work on a new major line in 3.3.0 in the coming weeks.
> >
> > In an effort to share the technical knowledge of "releasing TinkerPop",
> > we've
> > started to share the work of that process. While we've always had our
> > release
> > process documented[2] and a single release manager can handle releases,
> > we've determined it better (when possible) to have one release manager
> per
> > release line. Our initial trial with one release manager per version, on
> > the
> > previous release, worked well. We hope to continue with this approach for
> > future releases.
> >
> > Promotionally speaking, there have been a number of talks at conferences
> > on,
> > or related, to TinkerPop. As a sample, here are the talks given by PMC
> > members:
> >
> > Graph Computing with Apache TinkerPop - Dr. Marko Rodriguez [3]
> > Graph Processing with Titan and Scylla - Jason Plurad [4]
> >
> > On the brand management front, it was noted by a PMC member (Jason Plurad
> > had just been voted in almost to the day he made the report) that there
> > was
> > an individual selling products (baby clothes, mugs, t-shirts, etc.) on
> > Amazon
> > with TinkerPop graphics on them. Soon after, a second company was also
> > noted
> > selling similar products on an independent site. Neither, had permission
> > from
> > Apache to do that. After some discussion with Trademarks, the PMC chair
> > sent
> > notice to both sites requesting that they acknowledge the marks in their
> > product description. No response was received from the seller on Amazon,
> > but
> > all products were quickly removed. No response was received from the
> second
> > seller, but on greater inspection of the site, it doesn't really appear
> to
> > be
> > terribly active or maintained. Next steps with respect to this seller
> have
> > yet to be discussed.
> >
> > ## Issues:
> > There are no issues requiring board attention at this time.
> >
> > ## Releases:
> > - 3.1.4 (September 6, 2016)
> > - 3.2.2 (September 6, 2016)
> >
> > ## PMC/Committer:
> >
> > - Last PMC addition was Jason Plurad - August 2016
> > - Last committer addition was David Brown - August 2016
> >
> > ## Links
> >
> > [1] http://tinkerpop.apache.org/docs/current/reference/#gremlin-python
> > [2] http://tinkerpop.apache.org/docs/current/dev/developer/#_
> release_process
> > [3] https://www.youtube.com/watch?v=tLR-I53Gl9g
> > [4] https://www.youtube.com/watch?v=RllAy9OjzIo
>
>

Re: [DISCUSS] breaking gremlin-server.sh just a little

[Dylan Millikin]

I would wait for 3.3.0. I'm a little confused about the versions at the
moment as I thought our minor version 3.2.x should not be breaking (but
that doesn't seem to be the case since 3.2.2 was breaking compared to
3.2.0, though maybe that was a mishap).

Other than that the PR is a really nice one.

On Tue, Oct 4, 2016 at 8:28 AM, Stephen Mallette 
wrote:

> The more I think about this, the more I think I would just prefer to merge
> this on 3.3.0. We open that branch this weekend, so it's not as though
> we're pushing PR out too far. Not sure if that changes anyone's silence on
> this one, but that's what I'm thinking at this point.
>
> On Fri, Sep 30, 2016 at 12:30 PM, Stephen Mallette 
> wrote:
>
> > This is a very neat change I think - our gremlin-server.sh looks pretty
> > legit now. I'd just add one clarification that the proposal here is to
> push
> > this breaking change into the next release of 3.2.3. the question is
> > whether we wait for 3.3.0 which we would presumably start on pretty soon
> > (couple of weeks) to avoid pushing a breaking change into the 3.2.x line.
> > any thoughts on the matter?
> >
> > On Fri, Sep 30, 2016 at 12:22 PM, Robert Dale  wrote:
> >
> >> In relation to PR https://github.com/apache/tinkerpop/pull/439 , I'm
> >> proposing that gremlin-server.sh will be an init script.  As an init
> >> script, the expectation of not providing any parameters is to display
> >> usage/help:
> >>
> >> Usage: gremlin-server.sh {start|stop|restart|status|console|install
> >>   |}
> >>
> >> This breaks the current usage of starting the server in the foreground
> >> with the default yaml file.  Instead, a user would provide the command
> >> `console`.
> >>
> >> I have tried to keep other backwards compatibility by accepting `-i`
> >> (aka `install`) and a yaml file.  If the yaml file is the only
> >> parameter, the server will continue to start in the foreground.
> >>
> >> If there are no objections, then @spmallette will assume lazy
> >> consensus after 72 hours and do his thing.  I'm guessing.  ;-)
> >>
> >> --
> >> Robert Dale
> >>
> >
> >
>

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Dylan Millikin (JIRA)]

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

Dylan Millikin commented on TINKERPOP-1474:
---

I'm less torn about this now that GLVs are around the corner. It makes 
everything a little simpler for everyone and the extra consistency would be 
welcome. 

I'm just going to point out that I believe {{valueMap(true)}} on edges does not 
currently return {{inV/outV}}. If we go the {{Reference*}} route it would be 
nice to have those added in.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Store and Aggregate

[Dylan Millikin]

yeah I like the barrier().store() best as well.

On Wed, Sep 21, 2016 at 11:46 AM, Jean-Baptiste Musso 
wrote:

> I think barrier().store() for .aggregate() is very appropriate and fully
> tells what is going on.
>
> I like both, +1 for one or the other.
>
> People also tend to confuse .as() and .store()/.aggregate().
>
> On Tuesday, 20 September 2016, Marko Rodriguez 
> wrote:
>
> > Hi,
> >
> > I was thinking that store() and aggregate() should simply be “store().”
> >
> > store() -> store(local)
> > aggregate() -> store(global)
> >
> > Or:
> >
> > aggregate() ->  barrier().store()
> >
> > Random thoughts…
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> >
>
> --
> Jean-Baptiste
>

Re: Store and Aggregate

[Dylan Millikin]

+1 I find this to be way more explicit. Kinda got tripped by this a while
back.

On Tue, Sep 20, 2016 at 3:38 PM, Daniel Kuppitz  wrote:

> +1
>
> On Tue, Sep 20, 2016 at 3:35 PM, Marko Rodriguez 
> wrote:
>
> > Hi,
> >
> > I was thinking that store() and aggregate() should simply be “store().”
> >
> > store() -> store(local)
> > aggregate() -> store(global)
> >
> > Or:
> >
> > aggregate() ->  barrier().store()
> >
> > Random thoughts…
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
> >
> >
>

Re: [DISCUSS] Automated Tx Retry for Gremlin Server

[Dylan Millikin]

Yeah. This should be a client side feature.

I think discussing scenarios where retry is useful to clients and bubbling
up proper errors would be the correct solution to this problem. A good
example would be locks, currently clients have no clean way of detecting
locks and retrying appropriately.

On Mon, Sep 19, 2016 at 1:25 PM, Stephen Mallette 
wrote:

> A long while back I created this issue to support a way for Gremlin Server
> to retry failed transactions automatically. Aside from the difficulties
> discussed with Dylan in the issue itself, I'm realizing now that the
> complexity is more that Gremlin Server should probably bear.
>
> Barring objection I will assume lazy consensus after 72 hours (Thursday,
> September 22, 2016, 7am EST) and simply close this one:
>
> https://issues.apache.org/jira/browse/TINKERPOP-739
>

[jira] [Commented] (TINKERPOP-1427) GraphSON 2.0 needs collection types and consistent number typing.

[Dylan Millikin (JIRA)]

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

Dylan Millikin commented on TINKERPOP-1427:
---

I hear you, trust me. I'm just pointing out some potential conflicts. I'm not 
sure if this could be another but what of the Property typing for some DBs 
(like Titan). If you have a schema expecting Long are we going to have 
conflicts? 

> GraphSON 2.0 needs collection types and consistent number typing.
> -
>
> Key: TINKERPOP-1427
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1427
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Before 3.3.0, we need to get the story around collections straight. Currently 
> we are relying on JSON collections to represent our collections, but this 
> isn't always sound -- e.g. JSON maps can only have string keys.
> Thus, we need:
> {code}
> g:Map
> g:List
> g:Set
> {code}
> Note that all of these would just be JSON lists:
> {code}
> {@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
> {@type:"g:List", @value:[value1, value2, value3,...]}
> {@type:"g:Set", @value:[value1, value2, value3,...]}
> {code}
> ---
> Next, these data structures are exactly what play into {{aggregateTo}} in 
> sideEffects for {{RemoteConnection}}. Thus, we should use these types and, as 
> well, get rid of {{none}} as the aggregate would be a real type like 
> {{g:Int32}}.
> Also, I think we should abandon this hybrid physical machine naming 
> convention and programming language type convention.
> {code}
> g:Int32 -> g:Integer
> g:Int64 -> g:Long
> g:Double -> g:Double (no change)
> g:Float -> g:Float (no change)
> {code}
> If we want to be consistent either do the above or do the below, though I 
> think the above is cleaner.
> {code}
> g:Int32 -> g:Int32
> g:Int64 -> g:Int64
> g:Float -> g:Float32
> g:Double -> g:Float64
> {code}
> Again, using programming lexicon vs. physical machine lexicon is best and 
> thus, just gut "int32" and "int64."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] driver for gremlin-python

[Dylan Millikin]

Here are a couple ideas :

Simple : If we go the docker way, generate a test result recap file with
testIds that correspond to TinkerPop enforced tests. That way the test suit
can determine if a test was not performed or if a test failed. The testIds
would work something along the lines of  :
#1 : establish connection
#2 : test text/script for g.V()
#3 : test bytecode for g.V()
#4 : etc..

So your resulting recap file could be as simple as the above with
true/false markers next to the IDs. This means we still need to code the
tests in each language but at least there's good quality control.

Complexe: Allow GLVs to reverse Bytecode into their language.
[
[V, 1]
[outE, 'created']
[inV]
[repeat, [
[out, 'created']
[in, 'created']
]
[times, 5]
[valueMap, 'name', 'age']
]

would become

graph.traversal().V(1).outE('created').inV().repeat(out('created').in('created')).times(5).valueMap('name',
'age') in gremlin-groovy

$graph->traversal()->
V(1)->outE('created')->inV()->repeat($graph->traversal()->out('created')->in('created'))->times(5)->valueMap('name',
'age') in gremlin-php

etc...

This would have the advantage of allowing users to seamlessly translate
gremlin-x to their own language or any other (imagine documentation where
you can let users switch to their language dynamically or generate Cypher
from your glv, etc.). So long as lambdas aren't involved of course.

This could also allow us to make some TestProcessor for gremlin-server that
would submit code to exec to the clients and then test the request
messages. In which case all GLV test cases would be covered in one spot and
submitted to the GLVs. This has the downside of not really allowing lower
level driver testing though.

Crazy/impossible : Do the above but turn Bytecode into a language agnostic
language. Run any code you want in any language ;p  just sayin'





On Tue, Aug 16, 2016 at 9:45 AM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> Yeah - (1) is stinky. The more I think about it the more I don't think
> there is value in validating gremlin-python over Jython, if Jython is not
> up to date and, perhaps more importantly, not the environment users will
> run their code in. Doesn't seem to have much value in that case. Perhaps
> for 3.2.2 we don't have to try to tackle this testing issue completely.
>
> On Tue, Aug 16, 2016 at 9:31 AM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
> > For 1) maybe now is a good time to look into using docker for testing?
> That
> > would have it's own issues in the fact that testing would have to be
> > written directly in python so you would loose reusability for future GLVs
> > though.
> >
> > I'm not sure how to build a test suit that would either work across all
> > languages or enforce behaviors in all GLVs. I know this came up before I
> > just can't seem to find those issues. Might not be searching properly.
> >
> >
> > On Mon, Aug 15, 2016 at 4:29 PM, Stephen Mallette <spmalle...@gmail.com>
> > wrote:
> >
> > > After some review and tweaks, this PR from David just merged which got
> > the
> > > Python RemoteConnection going on TINKERPOP-1278:
> > >
> > > https://github.com/apache/tinkerpop/pull/379
> > >
> > > Still some work to do here:
> > >
> > > 1. Proper testing for Python's RemoteConnection implementation - ran
> into
> > > problems getting everything running under jython which is sorta out of
> > date
> > > with the latest python stuff. still trying to figure out what we want
> to
> > do
> > > there with respect to testing. basically we get some dependency errors
> > > around Python's fcntl, possibly related to: http://bugs.jython.org/
> > > issue1943
> > > - not completely sure what to do about that. On one hand we're using
> > Jython
> > > to test client side operations in the JVM environment so that we can
> get
> > > some re-use out of the full gremlin test suite (that's the good side).
> On
> > > the downside, no one will likely execute their gremlin-python code in
> > > Jython, we get bound to python 2.x where Jython appears largely stuck
> and
> > > we can't really work our way out of that bug anyway.  Anyway, Jython
> > still
> > > remains useful on the server where it will let us process python
> lambdas
> > > embedded in traversals - so even though you'd be bound to jython and
> > python
> > > 2.x for those lambdas that's still pretty neat. Solving this testing
> > issue
> > > is a top priority I think.
> > >
> > > 2. Making an actual "driver". Dave's PR focused on getting a Python
> > > RemoteConnection 

[jira] [Commented] (TINKERPOP-1407) Default serializers for Gremlin Server

[Dylan Millikin (JIRA)]

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

Dylan Millikin commented on TINKERPOP-1407:
---

+1 on this 

> Default serializers for Gremlin Server
> --
>
> Key: TINKERPOP-1407
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1407
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Priority: Minor
>
> If no serializers are configured then Gremlin Server is basically inoperable. 
> It probably shouldn't work that way. Would be better if some default 
> serializers were configured in that case - maybe gryo and the base graphson.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] driver for gremlin-python

[Dylan Millikin]

That makes perfect sense Stephen. Quick question regarding the last point
(testing environments and projects). Do you know what apache policies are
in regards to maintaining multiple repos for "official" plugins/GLVs? This
might make streamlining testing and updating the package in dependency
management systems easier (it's actually mandatory for php composer).
If you don't I can always bring it up with infra.

On Sat, Aug 6, 2016 at 6:47 AM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> Let me first address this piece:
>
> > My understanding around the driver needing modifications is -I'm
> guessing- mostly to accommodate for the updates in TINKERPOP-1278 rather
> than from drivers needing to be specific for GLVs. If not let me know.
>
> The modifications are mostly to trim down the size of gremlinclient and
> simplify. gremlinclient allowed for pluggable webscocket implementations
> and other stuff that adds some complexity/code we could be better without
> in TinkerPop. There are some specific updates needed for full support of
> GLVs. (i.e. collecting side-effects which i think can remain optional) but
> (I think) David's work can already submit bytecode (if not, then we'll need
> to change that too, but that's pretty trivial.
>
> As for the rest, which largely boils down to "consider depending on
> third-party drivers":
>
> I should have included some reasoning around your suggestion in my original
> post as this was a position in my mind that was considered. The problem
> with depending on third-party projects are the downsides you laid out and I
> think those are more than we should bear. I would also add to that list
> that the dependency is cyclical. The third party project depends on us then
> TinkerPop depends back on them. I don't imagine that this will necessarily
> cause a "compilation" problem but it doesn't seem quite natural/right.
>
> > Would it not be better to have GLV's simply depend on third party
> projects when they exist and are decently up to date)?
>
> The part in parenthesis is part of the problem in the long run. Code gets
> stale, people move on. It's easy to write a gremlin-driver on the weekend,
> but to build a driver on-par with the performance/features of the java
> driver - that's a difference story. Note that neo4j i think discovered this
> which is why they in-housed their drivers for bolt.
>
> >  If features are lacking the community can provide patches, etc.
>
> We could try and I would think most driver developers would be amenable to
> that, however some might not. Also the direction of an external project,
> might not match the direction TinkerPop wants. Apache governance doesn't
> extend to third-party projects so in the worst case, if we hit a wall on
> some technical issue that the owner of the project doesn't agree with, we'd
> be left with "find something else". In that case, TinkerPop has already
> spent a lot of time sending patches to that third-party and our time would
> have be wasted.
>
> > If a project dies we can always switch it out for another one.
>
> I don't know if it's that simple. Again, we'd (TinkerPop) presumably
> invested time getting a project on par with the java driver in terms of
> features and performance. So first of all, is there another project to
> switch to (right now there's not many second options for different
> languages)? And second, how much effort will there be to re-invest in a
> different driver to get it consistent with the features/performance of the
> java driver?
>
> > I just think that as we get more GLVs, providing CI with the correct
> environments
> to run various lower level driver tests in various languages is going to be
> a headache.
>
> Agreed. I worried about that too. However, this wont' be a fast process.
> We're not on a tear to build as many GLVs as possible. We're trying to get
> the model right with gremlin-python, set a high bar for the build
> automation needed, and then look at how to apply that elsewhere. If we can
> attain that same high bar, then we include a GLV. If we can't, then we wait
> until we can figure out how to. At least that's how I think about it.
>
> I'm not sure if any of that changes your position, but I believe the risks
> of depending on third-party drivers is a bit too high - at least higher
> than us having the extra code and build automation problems of owning the
> drivers ourselves.
>
>
> On Sat, Aug 6, 2016 at 1:26 AM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
> > If I may suggest an alternative. Most (all?) languages have dependency
> > management.
> > Would it not be better to have GLV's simply depend on third party
> projects
> > (when t

Re: [DISCUSS] Traversal with Java Serialization Removal

[Dylan Millikin]

+1 sounds good

On Fri, Jul 29, 2016 at 5:25 AM, Stephen Mallette 
wrote:

> I just created this issue:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1391
>
> As part of TINKERPOP-1278, I'd went ahead with deprecating the old method
> of sending a Traversal to the server. The approach taken there was to use
> java serialization to ship the Traversal to the server. The more I work on
> this though, the more it just looks like dead code that we really don't
> need to keep for any reason at all.
>
> Deprecation isn't really helping anyone out in this case as there are no
> drivers (save TinkerPop's gremlin-driver) that support this capability
> which is now wholly replaced by Bytecode serialization. Users won't know
> the difference as it is at a lower level of their concern and third-party
> drivers will be unaffected because they couldn't really support this
> "undocumented feature" anyway outside of the JVM.
>
> So, with all that reasoning, I'd just like to remove it all together and
> make some code look cleaner in the driver and server. The java
> serialization approach was a good experiment that helped lead us to the
> Bytecode solution and I think that's all it was ever really good for.
>
> Unless there are objections, I'll assume lazy consensus in 72 hours
> (Monday, August 1, 2016, 8:30am EST) and move forward with dropping it out.
>
> Thanks,
>
> Stephen
>

Re: [DISCUSS] Returning Side Effects

[Dylan Millikin]

> Perhaps nicer than doing all that trickery with transactions would be to
self-detach the vertex ahead of time

This was the original idea, I never dove too deep into it as the
sideEffects were applied mid traversal and extra filtering/SEs still had to
occur. I wasn't sure it was actually possible and the transaction hack
allowed me to move on.

As for the GLV limitations, it's mostly going to be network overhead.
Unfortunately one round trip with the server is costly and I know that
we've ended up having to be creative in order to limit the round trips by
concatenating scripts for each query. A GLV approach would need some
careful planing and probably a multiline byteCode feature. But I digress
that's not what this thread is about.

In the spirit of GLVs returning side effects how would your original
proposition stream over the network? Would you get all data first and then
SE? I'm guessing you would want to stream the SEs as well.

On Fri, Jul 22, 2016 at 4:42 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> > You can take the case of a group count as a really simple example.
>
> So you want the side-effect in the Vertex itself so you can use it with the
> ORM. Interesting. Perhaps nicer than doing all that trickery with
> transactions would be to self-detach the vertex ahead of time (i.e. create
> a DetachedVertex) and add the property you want. As indirect as that
> sounds, that seems more direct to me than the "fake" transaction. Not sure
> that what I'm doing here will help you with that problem.
>
> > I'll add that I'm looking at this from a non-GLV perspective so I'm
> disregarding object mapping done through GraphSONv2.0 typing in favor of a
> format guarantied result set (say that either only contains vertices,
>  edges, or a combination of both).
>
> Also interesting. Not sure that kind of serialization has a place in
> TinkerPop where we encourage folks to return everything under the sun by
> using Gremlin to return data in a form that suits their required end
> result. if this is the outcome you want, I think that my suggestion with
> self-detaching is probably on the right track. Maybe consider a custom
> serializer that coerces all results to a graph elements. That would take
> care of all the embedded objects and the whole lot.
>
> > The reason for this is that GLV is too
> inefficient for larger projects so a more traditional script->result
> approach is required.
>
> I'm hijacking my own thread by going too deep down this path, but I think
> we should strive toward a solution for GLVs to be robust enough for
> developers to be successful with TinkerPop in the language of their choice.
> Just like we'll never get rid of all lambdas in Gremlin, we will probably
> never quite get rid of script->result for all use cases (but, again, like
> lambdas the goal will be to get quite close). I find it quite interesting
> that we might be able to figure out how a python dev could write Gremlin in
> python that would remotely execute on the server seamlessly, however it's
> also interesting that that same GLV code could be treated as server-side to
> be accessed by from a python client. In that way, heavy complex logic (the
> type you are talking about) could be written in python and then accessed
> from python on the client. In short, i think that it would be better to
> prefer to think of the work around GLVs as "how to make Gremlin good in
> other languages" rather than the more narrow view of just "remoting
> traversals".  If we go wider, we might come up with some good ideas to
> really broaden access to TinkerPop and graphs in a very big way.
>
> We already have a really big improvement with "remoting" as compared to
> good 'ol RexsterGraph - so that's something  - haha  ;)
>
>
>
>
>
>
> On Fri, Jul 22, 2016 at 3:17 PM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
> > Yeah sorry I left out an important part. This is especially an issue when
> > you're dealing with an ORM layer that's expecting results of a specific
> > type (for example vertices).
> > You can take the case of a group count as a really simple example. Your
> > result set could be :
> >
> > [{count:5, vertex:v[1]}, {count:3, vertex:v[2]}, {count:1, vertex:v[3]}]
> > and this is easy enough to do with gremlin. But unless this is built into
> > the ORM itself chances are you'll need to implement the object mapping
> > yourself.
> >
> > The alternative is to add "count" as a property of vertex and then you
> can
> > leverage all available features from your ORM such as filtering,
> ordering,
> > etc... Actually, the way we did it above we can also do those directly in
> > gremlin as well

Re: [DISCUSS] Returning Side Effects

[Dylan Millikin]

Yeah sorry I left out an important part. This is especially an issue when
you're dealing with an ORM layer that's expecting results of a specific
type (for example vertices).
You can take the case of a group count as a really simple example. Your
result set could be :

[{count:5, vertex:v[1]}, {count:3, vertex:v[2]}, {count:1, vertex:v[3]}]
and this is easy enough to do with gremlin. But unless this is built into
the ORM itself chances are you'll need to implement the object mapping
yourself.

The alternative is to add "count" as a property of vertex and then you can
leverage all available features from your ORM such as filtering, ordering,
etc... Actually, the way we did it above we can also do those directly in
gremlin as well.

This is a simple case, but once it gets more complicated with hierarchical
data, the option of implementing the object mapping yourself is just a
headache and often times less efficient than just rolling back a
transaction.

Dunno if that was clear enough this time around.

I'll add that I'm looking at this from a non-GLV perspective so I'm
disregarding object mapping done through GraphSONv2.0 typing in favor of a
format guarantied result set (say that either only contains vertices,
 edges, or a combination of both). The reason for this is that GLV is too
inefficient for larger projects so a more traditional script->result
approach is required.

On Fri, Jul 22, 2016 at 2:09 PM, Stephen Mallette <spmalle...@gmail.com>
wrote:

> hi dylan, could you please provide a more concrete example of the problem
> you're facing?
>
> On Fri, Jul 22, 2016 at 1:24 PM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
> > I'm going to confirm that this is actually a common issue.
> > One thing to keep in mind is that often times the sideEffects are
> directly
> > linked to returned elements on a 1 --> n basis which neither of the above
> > really help with. That is to say that if you're streaming your results
> > you'll need the sideEffects that relate to the streamed element.
> >
> > There is no easy way of handling this currently. Especially if you order
> > your results and get unordered sideEffect results.
> > One way we've found to work around this is very hacky, not efficient and
> > only works for non mutating queries:
> >
> > - we start a transaction
> > - we append the sideEffect data to the elements we're emitting (say as
> > properties of a vertex)
> > - get the full result set with sideEffects as properties of the result
> > elements.
> > - rollback transaction so properties are not persisted to the graph.
> >
> > A truly wicked succession of events born from absolute desperation.
> > I enquired a while back about the ability to treat elements as detached
> > from the graph in order to do the above without the transaction handling.
> > But I never followed up.
> >
> > I figured I would put this out there as another case where non-Java
> > languages struggle.
> >
> > On Thu, Jul 21, 2016 at 1:19 PM, Stephen Mallette <spmalle...@gmail.com>
> > wrote:
> >
> > > Your way made me think that if you wrote your traversal like that, you
> > > would return the side-effects twice - once in your traversal as part of
> > the
> > > standard result and then again as a side-effect.  Not sure what that
> > means
> > > - just a thought.
> > >
> > > While I'm thinking thoughts that may or may not be obvious, it also
> > occurs
> > > to me that the downside for a GLV retrieving data that way is that the
> > > result of the traversal won't be streamed back. It will aggregate the
> > > result (and the side-effects naturally) in memory and then return that
> > all
> > > as a whole.
> > >
> > > On Thu, Jul 21, 2016 at 11:24 AM, Daniel Kuppitz <m...@gremlin.guru>
> > wrote:
> > >
> > > > If you really want to have your result and your side-effects returned
> > by
> > > a
> > > > single request, you could do something like this:
> > > >
> > > > gremlin>
> > > >
> > > >
> > >
> >
> g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().as("data").select("data",
> > > > "names", "ages")*
> > > > ==>[data:[v[1], v[2], v[4]], names:[marko, vadas, josh], ages:[29,
> 27,
> > > 32]]
> > > > gremlin>
> > > >
> > > >
> > >
> >
> g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("

Re: [DISCUSS] Returning Side Effects

[Dylan Millikin]

I'm going to confirm that this is actually a common issue.
One thing to keep in mind is that often times the sideEffects are directly
linked to returned elements on a 1 --> n basis which neither of the above
really help with. That is to say that if you're streaming your results
you'll need the sideEffects that relate to the streamed element.

There is no easy way of handling this currently. Especially if you order
your results and get unordered sideEffect results.
One way we've found to work around this is very hacky, not efficient and
only works for non mutating queries:

- we start a transaction
- we append the sideEffect data to the elements we're emitting (say as
properties of a vertex)
- get the full result set with sideEffects as properties of the result
elements.
- rollback transaction so properties are not persisted to the graph.

A truly wicked succession of events born from absolute desperation.
I enquired a while back about the ability to treat elements as detached
from the graph in order to do the above without the transaction handling.
But I never followed up.

I figured I would put this out there as another case where non-Java
languages struggle.

On Thu, Jul 21, 2016 at 1:19 PM, Stephen Mallette 
wrote:

> Your way made me think that if you wrote your traversal like that, you
> would return the side-effects twice - once in your traversal as part of the
> standard result and then again as a side-effect.  Not sure what that means
> - just a thought.
>
> While I'm thinking thoughts that may or may not be obvious, it also occurs
> to me that the downside for a GLV retrieving data that way is that the
> result of the traversal won't be streamed back. It will aggregate the
> result (and the side-effects naturally) in memory and then return that all
> as a whole.
>
> On Thu, Jul 21, 2016 at 11:24 AM, Daniel Kuppitz  wrote:
>
> > If you really want to have your result and your side-effects returned by
> a
> > single request, you could do something like this:
> >
> > gremlin>
> >
> >
> g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().as("data").select("data",
> > "names", "ages")*
> > ==>[data:[v[1], v[2], v[4]], names:[marko, vadas, josh], ages:[29, 27,
> 32]]
> > gremlin>
> >
> >
> g.V(1,2,4).aggregate("names").by("name").aggregate("ages").by("age")*.fold().project("data",
> > "se").by().by(cap("names","ages"))*
> > ==>[data:[v[1], v[2], v[4]], se:[names:[marko, vadas, josh], ages:[29,
> 27,
> > 32]]]
> > gremlin> g.V(1,2,4).aggregate("names").by("name")*.fold().project("data",
> > "se").by().by(cap("names"))*
> > ==>[data:[v[1], v[2], v[4]], se:[marko, vadas, josh]]
> >
> > I'm not saying it would be bad to have Gremlin Server handle that for
> you,
> > just wanted to show that it's actually pretty easy to get the data and
> the
> > side-effects without using the traversal admin methods (hence it should
> > work for all GLVs).
> >
> > Cheers,
> > Daniel
> >
> >
> > On Thu, Jul 21, 2016 at 4:51 PM, Stephen Mallette 
> > wrote:
> >
> > > As we look to build out GLVs and expand Gremlin into other programming
> > > languages, one of the important aspects of doing this should be to
> > consider
> > > consistency across GLVs. We should try to prevent capabilities of Java
> > from
> > > being lost in Python, JS, etc.
> > >
> > > As we look at both RemoteGraph in Java and gremlin-python we find that
> > > there is no way to get traversal side-effects. If you write a Traversal
> > and
> > > want side-effects from it, you have to write your traversal to return
> > them
> > > so that it comes back as part of the result set. Since RemoteGraph and
> > > gremlin-python don't really allow you to directly "submit a script"
> it's
> > > not as though you can execute a traversal once for both the result and
> > the
> > > side-effect and package them together in a single request as you might
> do
> > > with a simple script request:
> > >
> > > $ curl -X POST -d
> > >
> > >
> >
> "{\"gremlin\":\"t=g.V(1).values('name').aggregate('x');[v:t.toList(),se:t.getSideEffects().get('x')]\"}"
> > > http://localhost:8182
> > >
> > >
> >
> {"requestId":"3d3258b2-e421-459a-bf53-ea1e58ece4aa","status":{"message":"","code":200,"attributes":{}},"result":{"data":[{"v":["marko"]},{"se":["marko"]}],"meta":{}}}
> > >
> > > I'm thinking that we could alter things in a non-breaking way to allow
> > > optional return of side-effect data so that there is a way to have this
> > all
> > > streamed back without the need for the little workaround I just
> > > demonstrated. For REST I think we could just include a sideEffect
> request
> > > parameter that allowed for a list of side-effect keys to return.
> Perhaps
> > > the a "*" could indicate that all should be returned.  the side-effects
> > > could be serialized into a key sibling to "data" called "sideEffect".
> > >
> > > I think a similar approach could be used for websockets and NIO where
> we
> > 

Re: [VOTE] TinkerPop 3.2.1 Release

[Dylan Millikin]

Ran all the driver tests again neo4j and tinkerpop and everything works as
expected.

VOTE: +1

On Tue, Jul 19, 2016 at 9:20 AM, Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.2.1 is ready for release - note
> the lack of "-incubating" everywhere.  :)
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.1/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.1-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-gremlin-console-3.2.1-bin.zip
> apache-gremlin-server-3.2.1-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.2.1/reference/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.1/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.2.1/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.2.1/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=c5a9e2815e76f044e6b33b773b6bb0bb048270cc
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/3.2.1/CHANGELOG.asciidoc#release-3-2-1
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (July 22,
> 2016) at 9:30 am EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Dylan Millikin]

Quick question which is probably handled automatically but is this working
with multiple cardinalities on properties?

On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com <
gallardo.kev...@gmail.com> wrote:

>
>
> On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"<
> gallardo.kev...@gmail.com> wrote:
> >
> >
> > On 2016-07-09 16:48 (+0100), Stephen Mallette 
> wrote:
> > > With all the work on GLVs and the recent work on GraphSON 2.0, I think
> it's
> > > important that we have a solid, efficient, programming language
> neutral,
> > > lossless serialization format. Right now that format is GraphSON and it
> > > works for that purpose (ever more  so with 2.0). Given some discussion
> on
> > > the GraphSON 2.0 PR driven a bit by Robert Dale:
> > >
> > > https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> > >
> > > I wonder if we shouldn't consider another IO format that has Gremlin
> > > Server/GLVs in mind. At this point I'm not suggesting anything
> specific -
> > > I'm just hanging the idea out for further discussion and brain
> storming.
> > > Thoughts?
> > >
> >
> > Hey, so I'm trying to gather all infos we have here in order to prepare
> to move forward with the implem of GraphSON 2.0, here's what I come up with
> :
> >
> > Things we have :
> > - Type format.
> > - The structure in Jackson to implement our own type format.
> > - All non native Graph types are typed (except the domain specific
> types).
> >
> > New things we need :
> > - Types for domain specific objects.
> > - Types for all numeric values.
> > - Don't serialize empty fields (outV and stuff).
> >
> > Things we consider changing :
> > - Type IDs convention. Before : Java simple class names. Now : starts
> with a "domain" like "gremlin" followed by the "type name", which is a
> lowercased type name (like "uuid", or "float", or "vertex"). Example :
> "gremlin:uuid".
> > - Type format ?
> >
> > Am I missing something ?
> >
> Hey,
>
> So I've made a few changes in the code from the original GraphSON 2.0,
> with the objectives described above, the code is still messy but I just
> thought I'd share some samples to start getting into the work and gather
> some feedback.
>
> In the example I've created a TinkerGraph with 2 vertices connected by an
> edge. The graph is serialized as a TinkerGraph.
> The samples are there :
> https://gist.github.com/newkek/97da94342bc32e571cf4a0ba1018df60
>
> Any feedback appreciated.
>

Re: [DISCUSS] 3.1.x code line

[Dylan Millikin]

+1 from me as well. Sounds good.

On Thu, Jul 14, 2016 at 2:14 PM, Ted Wilmes  wrote:

> It does for me too, +1.
>
> --Ted
>
> On Wed, Jul 13, 2016 at 3:44 PM, Hadrian Zbarcea 
> wrote:
>
> > +1. It does to me.
> > Hadrian
> >
> >
> > On 07/13/2016 04:29 PM, Stephen Mallette wrote:
> >
> >> Since we don't really follow semantic versioning for releases, I thought
> >> we
> >> should discuss the 3.1.x code line. We've been steadily adding features
> >> right up to our current 3.1.3 release which we will vote on shortly. I
> >> think it's pretty awesome that we've managed to maintain that older line
> >> of
> >> code for as long as we have and I think we've evolved it in a very
> >> sensible
> >> way.
> >>
> >> I think we should continue to maintain 3.1.x after the 3.1.3 release,
> >> which
> >> would mean a 3.1.4 release at some point, but we should strictly limit
> the
> >> changes there to bug fixes and not do any "new features" on that line of
> >> code (i.e the tp31 branch). As it stands, I don't see any open "bugs"
> for
> >> the 3.1.3 in JIRA so as of right now, we wouldn't have much planned for
> >> 3.1.4.
> >>
> >> Does that make sense for everyone?
> >>
> >>
>

Re: Unicorn supports their own version of Gremlin.

[Dylan Millikin]

Maybe working on referencing these pages via perhaps a blog post from
someone would be cool. Something along the lines of "Creating a graph db
with Tinkerpop" or some other variation that may get good hit results in a
google search.

On Wed, May 25, 2016 at 10:06 AM, Stephen Mallette 
wrote:

> We've seen a lot of new graphs come out that don't do TinkerPop from the
> start. Perhaps they make a conscious decision not to - i dunno. I just
> wonder if part of the problem is the provider docs for doing an
> implementation:
>
> http://tinkerpop.apache.org/docs/3.2.0-incubating/dev/provider/
>
> are they easy enough to find? do folks understand them and what it means to
> be tinkerpop-enabled? the docs could probably be improved - any graph
> providers out there want to take a stab at it? in some ways your external
> experience at implementing might be helpful in improving them.
>
> On Tue, May 24, 2016 at 12:40 PM, Marko Rodriguez 
> wrote:
>
> > Hi,
> >
> > See https://github.com/haifengl/unicorn
> >
> > They say they support a "Gremlin-like API." It would be really cool if
> > they just implemented TinkerPop's Graph API. Perhaps someone feels like
> > creating a ticket at their main repo explaining how to go about
> supporting
> > TinkerPop? Or, even better, providing them a PR!
> >
> >  https://github.com/adplabs/unicorn
> >
> > Take care,
> > Marko.
> >
> > http://markorodriguez.com
> >
> >
>

Re: [TinkerPop] TinkerPop Graduates from Incubation

[Dylan Millikin]

Grats guys. I'm genuinely excited about this.
Thanks to everyone who worked so hard to make this happen.

On Mon, May 23, 2016 at 10:49 AM, Marko Rodriguez 
wrote:

> Congratulations everyone --- and thank you Stephen for being the Chair of
> the project. You are perfect for the task at hand and what is to come.
>
> Take care,
> Marko.
>
> On May 23, 2016, at 7:53 AM, Jason Plurad  wrote:
>
> +1 to all the TinkerPoppers out there that contributed!
>
> On Monday, May 23, 2016 at 9:09:43 AM UTC-4, Stephen Mallette wrote:
>>
>> Hello TinkerPop - after about 18 months of incubating, we've incubated
>> all we can incubate in the Apache Incubator and the incubation to end all
>> incubations has culminated with Apache TinkerPop becoming a top-level
>> project at Apache. Please see the official announcement here on the Apache
>> Software Foundation blog:
>>
>>
>> https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces91
>>
>>
>> [image: Media preview]
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/f7094e5d-2e16-4ddc-96b7-d8bf63ac4239%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Gremlin-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gremlin-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gremlin-users/34E6145B-367F-4F86-B684-35F92BA865F5%40gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>