Re: [DISCUSS] Is null equal to null

[David Bechberger]

Hello Ken,

I don't know that I have a strong opinion on what NULL==NULL should
evaluate to, but I agree we should come up with a set of rules here for
consistency, both within Gremlin but also with other database language
standards (e.g. GQL and SQL) so that Gremlin best matches customer
expectations.  Gremlin's divergence from user expectations when it comes to
null handling has been a constant headache for new users.  While I agree
with Josh that a type system would make this easier, we still need to be
consistent until we cross that bridge.

For example, if you have a list, A, which is
[1,2,null] and a list, B, which is [1,null]. Should the result of an
INTERSECT be [1,null] or [1]

In Postgres, this would be [1,null] so that is probably what I would
recommend unless someone has a stronger opinion to do something different?

Josh, I am familiar with the work you did on Dragon, and I am curious how
you see your work aligning with the recent SIGMOD paper [1] from the LDBC
working group on PG Schema?

Dave

[1] https://arxiv.org/abs/2211.10962


On Sat, Aug 5, 2023 at 7:02 AM Joshua Shinavier  wrote:

> Hi Ken,
>
> Yes indeed, there is that push. I am not saying that Gremlin shouldn't have
> a type system -- just that certain questions will have better answers once
> it does. While I am not drawing a lot of attention to it yet in connection
> with TinkerPop, there is a type system I am going to propose for TinkerPop.
> The formalism is called Lambda Graph, and it is closely related to the
> Algebraic Property Graphs [1] model which was implemented by Dragon [2]. I
> made a big deal about Dragon three years ago and then was unable to release
> it, so I'm waiting until Hydra [3] is completely ready before promoting it
> here. That said, it's not far from being ready. We are building property
> graph (not yet TinkerPop) applications with it at LinkedIn. I recently gave
> a presentation [4] on the data model which has excerpts from the Lambda
> Graph paper draft. In terms of property types, probably the first thing I
> will explore is integrating Hydra's "TinkerPop" model [5] with TinkerPop
> proper. In that model, property types are parameterized and unspecified, as
> are vertex and edge id types; different type systems for properties and ids
> can be plugged in here. For Hydra's core type system, see hydra/core.Type
> [6]. This type system behaves as I described above: there are no "nulls",
> but there are optionals, which are comparable to the extent that the base
> type is comparable.
>
> Josh
>
> [1] https://arxiv.org/abs/1909.04881
> [2] https://www.uber.com/blog/dragon-schema-integration-at-uber-scale/
> [3] https://github.com/CategoricalData/hydra
> [4]
>
> https://docs.google.com/presentation/d/1PF0K3KtopV0tMVa0sGBW2hDA7nw-cSwQm6h1AED1VSA
> [5]
>
> https://categoricaldata.github.io/hydra/hydra-java/javadoc/hydra/langs/tinkerpop/propertyGraph/package-summary.html
> [6]
>
> https://categoricaldata.github.io/hydra/hydra-java/javadoc/hydra/core/Type.html
>
>
> On Fri, Aug 4, 2023 at 6:23 PM Ken Hu 
> wrote:
>
> > Hi Josh,
> >
> > Thanks for your input. There seems to be a push in the graph database
> world
> > towards having a schema. It's likely something like this would be
> > introduced in TinkerPop in the future. Let's assume that TinkerPop does
> > support schemas, and therefore would have a type system, would this
> change
> > your opinion on the matter?
> >
> > Thanks again,
> > Ken
> >
> > On Wed, Aug 2, 2023 at 3:54 PM Joshua Shinavier 
> wrote:
> >
> > > For what it is worth, I think the question of whether null == null is
> > only
> > > meaningful in the context of a specific type system, which Gremlin so
> far
> > > does not provide. My personal preference is to avoid SQL-style nulls
> and
> > > achieve optionality through union types (e.g. Java's Optional or
> > Haskell's
> > > Maybe). In the case of two lists, if you can assume that the type of
> the
> > > list is list>, then you can safely treat null like
> > > Optional.empty(), and compare it with another null of the same logical
> > type
> > > (int). If that is the interpretation of your two lists, then the
> > > intersection is [1, null].
> > >
> > > Josh
> > >
> > >
> > >
> > > On Tue, Aug 1, 2023 at 5:47 PM Ken Hu 
> > > wrote:
> > >
> > > > Hi All,
> > > >
> > > > As Gremlin evolves and gains more functionality, it is important that
> > we
> > > > establish some fundamental rules to provide consistency in results.
> One
> > > > such question that we should come to agreement on is how null values
> > are
> > > > compared. Currently, Gremlin seems to mostly follow the comparison
> that
> > > is
> > > > used in Java where NULL == NULL returns TRUE. However, in many other
> > > > database systems, NULL == NULL would return FALSE (or NULL).
> > > >
> > > > This question comes about as I'm starting to look a little deeper
> into
> > > the
> > > > proposed list functions. An example of where this is applicable is
> the
> > > > INTERSECT 

Re: [DISCUSS] - Proposal for Removing the Need for Closure/Lambda with String/List/Date functions

[David Bechberger]

Thanks to everyone who provided feedback so far.  Are there any other
comments?  If not, then I'd like to get this merged in this week, so we can
get started with implementation.

Dave

On Mon, Feb 27, 2023 at 8:31 PM Dave Bechberger  wrote:

> Thanks to everyone who gave feedback so far. Any other comments on this
> proposal?
>
> I’d like to get this merged in this week so we can get started with
> implementation.
>
> Dave Bechberger
>
>
> On Feb 17, 2023, at 7:18 AM, David Bechberger  wrote:
>
> 
> I was two fast on my reply before as I did have a question for you
> Valentyn on this statement:
>
>
> *I would propose to consider adding `startWith`, `endWith` andmaybe
> `contains` string functions.*
>
> How would you see these steps being used differently than the current
> predicates?
>
> i.e. P.startingWith()/endingWith()/containing()
>
> Dave
>
> On Fri, Feb 17, 2023 at 7:12 AM David Bechberger 
> wrote:
>
>> Thank you for the fixes Valentyn, I've incorporated that PR.
>>
>> The list I proposed here was a minimum number of functions, so we can
>> definitely see what it would take to include something like a string
>> formatting function.
>>
>> Dave
>>
>> On Thu, Feb 16, 2023 at 8:36 AM Valentyn Kahamlyk
>>  wrote:
>>
>>> Hi,
>>>
>>> Dave, thank you for the detailed proposal!
>>>
>>> I made small PR with naming fixes:
>>> https://github.com/apache/tinkerpop/pull/1973, please take a look.
>>>
>>> Also I would propose to consider adding `startWith`, `endWith` and
>>> maybe `contains` string functions.
>>>
>>> Another interesting feature to keep in mind is string formatting.
>>> for example
>>> `g.V(1).values('first_name').concat(' ').concat(V(1).values('last_name')`
>>> can be simplified as
>>> `g.V(1).asString('%s %s', values('first_name'), values('last_name'))`
>>>
>>> Regards, Valentyn
>>>
>>>
>>> On Tue, Feb 14, 2023 at 8:47 AM David Bechberger 
>>> wrote:
>>>
>>> > My apologies, I just saw that I didn't include a link in that email.
>>> The
>>> > proposal is here:
>>> >
>>> >
>>> >
>>> https://github.com/apache/tinkerpop/blob/proposal_3/docs/src/dev/future/proposal-3-remove-closures.asciidoc
>>> >
>>> > Dave
>>> >
>>> > On Tue, Feb 14, 2023 at 7:09 AM David Bechberger 
>>> > wrote:
>>> >
>>> > > Hi All,
>>> > >
>>> > > There are a number of useful operations that Gremlin users often
>>> wish to
>>> > > perform that are not provided today in the form of traversal steps or
>>> > > predicates (P/TextP). For historical reasons these functions were
>>> omitted
>>> > > and users were able to accomplish these tasks by specifying anonymous
>>> > code
>>> > > blocks or “closures” to perform these tasks. For example, below is an
>>> > > example of how you can achieve a case-insensitive search for any
>>> cities
>>> > > that contain “Miami”.
>>> > >
>>> > > g.V().hasLabel('city').
>>> > >
>>> > >
>>> >
>>> has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())})
>>> > >
>>> > > While this is a powerful fallback mechanism in Gremlin to handle use
>>> > cases
>>> > > where there is no functionality within the Gremlin language to meet
>>> the
>>> > > requirements. However, for a variety of reasons such as security and
>>> > > performance, many/most remote providers of TinkerPop do not allow
>>> users
>>> > to
>>> > > execute closures as part of a query. This leaves users with a
>>> problem, as
>>> > > the mechanism provided to solve these sorts of use cases is not
>>> allowed.
>>> > I
>>> > > have come up with a proposed framework for removing the need for
>>> closures
>>> > > by adding the most commonly requested functions as new Gremlin steps.
>>> > > Below is a proposal to highlight this and propose a first set of
>>> these
>>> > > steps for string manipulation, list manipulation, and data
>>> manipulation.
>>> > >
>>> > > What are your thoughts on this approach?
>>> > > Any items we missed?
>>> > > Concerns?
>>> > >
>>> > > Thanks,
>>> > > Dave
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] - Proposal for Removing the Need for Closure/Lambda with String/List/Date functions

[David Bechberger]

I was two fast on my reply before as I did have a question for you Valentyn
on this statement:


*I would propose to consider adding `startWith`, `endWith` andmaybe
`contains` string functions.*

How would you see these steps being used differently than the current
predicates?

i.e. P.startingWith()/endingWith()/containing()

Dave

On Fri, Feb 17, 2023 at 7:12 AM David Bechberger 
wrote:

> Thank you for the fixes Valentyn, I've incorporated that PR.
>
> The list I proposed here was a minimum number of functions, so we can
> definitely see what it would take to include something like a string
> formatting function.
>
> Dave
>
> On Thu, Feb 16, 2023 at 8:36 AM Valentyn Kahamlyk
>  wrote:
>
>> Hi,
>>
>> Dave, thank you for the detailed proposal!
>>
>> I made small PR with naming fixes:
>> https://github.com/apache/tinkerpop/pull/1973, please take a look.
>>
>> Also I would propose to consider adding `startWith`, `endWith` and
>> maybe `contains` string functions.
>>
>> Another interesting feature to keep in mind is string formatting.
>> for example
>> `g.V(1).values('first_name').concat(' ').concat(V(1).values('last_name')`
>> can be simplified as
>> `g.V(1).asString('%s %s', values('first_name'), values('last_name'))`
>>
>> Regards, Valentyn
>>
>>
>> On Tue, Feb 14, 2023 at 8:47 AM David Bechberger 
>> wrote:
>>
>> > My apologies, I just saw that I didn't include a link in that email.
>> The
>> > proposal is here:
>> >
>> >
>> >
>> https://github.com/apache/tinkerpop/blob/proposal_3/docs/src/dev/future/proposal-3-remove-closures.asciidoc
>> >
>> > Dave
>> >
>> > On Tue, Feb 14, 2023 at 7:09 AM David Bechberger 
>> > wrote:
>> >
>> > > Hi All,
>> > >
>> > > There are a number of useful operations that Gremlin users often wish
>> to
>> > > perform that are not provided today in the form of traversal steps or
>> > > predicates (P/TextP). For historical reasons these functions were
>> omitted
>> > > and users were able to accomplish these tasks by specifying anonymous
>> > code
>> > > blocks or “closures” to perform these tasks. For example, below is an
>> > > example of how you can achieve a case-insensitive search for any
>> cities
>> > > that contain “Miami”.
>> > >
>> > > g.V().hasLabel('city').
>> > >
>> > >
>> >
>> has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())})
>> > >
>> > > While this is a powerful fallback mechanism in Gremlin to handle use
>> > cases
>> > > where there is no functionality within the Gremlin language to meet
>> the
>> > > requirements. However, for a variety of reasons such as security and
>> > > performance, many/most remote providers of TinkerPop do not allow
>> users
>> > to
>> > > execute closures as part of a query. This leaves users with a
>> problem, as
>> > > the mechanism provided to solve these sorts of use cases is not
>> allowed.
>> > I
>> > > have come up with a proposed framework for removing the need for
>> closures
>> > > by adding the most commonly requested functions as new Gremlin steps.
>> > > Below is a proposal to highlight this and propose a first set of these
>> > > steps for string manipulation, list manipulation, and data
>> manipulation.
>> > >
>> > > What are your thoughts on this approach?
>> > > Any items we missed?
>> > > Concerns?
>> > >
>> > > Thanks,
>> > > Dave
>> > >
>> >
>>
>

Re: [DISCUSS] - Proposal for Removing the Need for Closure/Lambda with String/List/Date functions

[David Bechberger]

Thank you for the fixes Valentyn, I've incorporated that PR.

The list I proposed here was a minimum number of functions, so we can
definitely see what it would take to include something like a string
formatting function.

Dave

On Thu, Feb 16, 2023 at 8:36 AM Valentyn Kahamlyk
 wrote:

> Hi,
>
> Dave, thank you for the detailed proposal!
>
> I made small PR with naming fixes:
> https://github.com/apache/tinkerpop/pull/1973, please take a look.
>
> Also I would propose to consider adding `startWith`, `endWith` and
> maybe `contains` string functions.
>
> Another interesting feature to keep in mind is string formatting.
> for example
> `g.V(1).values('first_name').concat(' ').concat(V(1).values('last_name')`
> can be simplified as
> `g.V(1).asString('%s %s', values('first_name'), values('last_name'))`
>
> Regards, Valentyn
>
>
> On Tue, Feb 14, 2023 at 8:47 AM David Bechberger 
> wrote:
>
> > My apologies, I just saw that I didn't include a link in that email.  The
> > proposal is here:
> >
> >
> >
> https://github.com/apache/tinkerpop/blob/proposal_3/docs/src/dev/future/proposal-3-remove-closures.asciidoc
> >
> > Dave
> >
> > On Tue, Feb 14, 2023 at 7:09 AM David Bechberger 
> > wrote:
> >
> > > Hi All,
> > >
> > > There are a number of useful operations that Gremlin users often wish
> to
> > > perform that are not provided today in the form of traversal steps or
> > > predicates (P/TextP). For historical reasons these functions were
> omitted
> > > and users were able to accomplish these tasks by specifying anonymous
> > code
> > > blocks or “closures” to perform these tasks. For example, below is an
> > > example of how you can achieve a case-insensitive search for any cities
> > > that contain “Miami”.
> > >
> > > g.V().hasLabel('city').
> > >
> > >
> >
> has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())})
> > >
> > > While this is a powerful fallback mechanism in Gremlin to handle use
> > cases
> > > where there is no functionality within the Gremlin language to meet the
> > > requirements. However, for a variety of reasons such as security and
> > > performance, many/most remote providers of TinkerPop do not allow users
> > to
> > > execute closures as part of a query. This leaves users with a problem,
> as
> > > the mechanism provided to solve these sorts of use cases is not
> allowed.
> > I
> > > have come up with a proposed framework for removing the need for
> closures
> > > by adding the most commonly requested functions as new Gremlin steps.
> > > Below is a proposal to highlight this and propose a first set of these
> > > steps for string manipulation, list manipulation, and data
> manipulation.
> > >
> > > What are your thoughts on this approach?
> > > Any items we missed?
> > > Concerns?
> > >
> > > Thanks,
> > > Dave
> > >
> >
>

Re: [DISCUSS] - Proposal for Removing the Need for Closure/Lambda with String/List/Date functions

[David Bechberger]

My apologies, I just saw that I didn't include a link in that email.  The
proposal is here:

https://github.com/apache/tinkerpop/blob/proposal_3/docs/src/dev/future/proposal-3-remove-closures.asciidoc

Dave

On Tue, Feb 14, 2023 at 7:09 AM David Bechberger 
wrote:

> Hi All,
>
> There are a number of useful operations that Gremlin users often wish to
> perform that are not provided today in the form of traversal steps or
> predicates (P/TextP). For historical reasons these functions were omitted
> and users were able to accomplish these tasks by specifying anonymous code
> blocks or “closures” to perform these tasks. For example, below is an
> example of how you can achieve a case-insensitive search for any cities
> that contain “Miami”.
>
> g.V().hasLabel('city').
>
> has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())})
>
> While this is a powerful fallback mechanism in Gremlin to handle use cases
> where there is no functionality within the Gremlin language to meet the
> requirements. However, for a variety of reasons such as security and
> performance, many/most remote providers of TinkerPop do not allow users to
> execute closures as part of a query. This leaves users with a problem, as
> the mechanism provided to solve these sorts of use cases is not allowed. I
> have come up with a proposed framework for removing the need for closures
> by adding the most commonly requested functions as new Gremlin steps.
> Below is a proposal to highlight this and propose a first set of these
> steps for string manipulation, list manipulation, and data manipulation.
>
> What are your thoughts on this approach?
> Any items we missed?
> Concerns?
>
> Thanks,
> Dave
>

[DISCUSS] - Proposal for Removing the Need for Closure/Lambda with String/List/Date functions

[David Bechberger]

Hi All,

There are a number of useful operations that Gremlin users often wish to
perform that are not provided today in the form of traversal steps or
predicates (P/TextP). For historical reasons these functions were omitted
and users were able to accomplish these tasks by specifying anonymous code
blocks or “closures” to perform these tasks. For example, below is an
example of how you can achieve a case-insensitive search for any cities
that contain “Miami”.

g.V().hasLabel('city').

has('name',filter{it.get().toLowerCase().contains('Miami'.toLowerCase())})

While this is a powerful fallback mechanism in Gremlin to handle use cases
where there is no functionality within the Gremlin language to meet the
requirements. However, for a variety of reasons such as security and
performance, many/most remote providers of TinkerPop do not allow users to
execute closures as part of a query. This leaves users with a problem, as
the mechanism provided to solve these sorts of use cases is not allowed. I
have come up with a proposed framework for removing the need for closures
by adding the most commonly requested functions as new Gremlin steps.
Below is a proposal to highlight this and propose a first set of these
steps for string manipulation, list manipulation, and data manipulation.

What are your thoughts on this approach?
Any items we missed?
Concerns?

Thanks,
Dave

Re: [VOTE] TinkerPop 3.6.2 Release

[David Bechberger]

Looks good to me

VOTE +1 (non-binding)

On Mon, Jan 23, 2023 at 10:29 AM Ken Hu 
wrote:

> Thanks Yang. This looks good to me.
>
> VOTE +1 (non-binding)
>
> On Mon, Jan 23, 2023 at 10:05 AM Cole Greer
>  wrote:
>
> > Thanks for putting this all together Yang. I’ve dug through the docs and
> > artifacts and it all looks good to me.
> >
> > VOTE +1 (non-binding)
> >
> > Regards,
> >
> > Cole Greer
> >
> >
> > From: Valentyn Kahamlyk 
> > Date: Monday, January 23, 2023 at 9:16 AM
> > To: dev@tinkerpop.apache.org 
> > Subject: Re: [VOTE] TinkerPop 3.6.2 Release
> > Yang, thank you for preparing the release!
> >
> > VOTE +1 (non-binding)
> >
> > On Mon, Jan 23, 2023 at 8:16 AM Florian Hockmann  >
> > wrote:
> >
> > > I had the same problem with bin/validate-distribution.sh as in the
> other
> > > thread, but again, this shouldn't be a problem for the release
> process. I
> > > again skimmed over the docs and everything looks good to me.
> > >
> > > VOTE +1
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Yang Xia 
> > > Gesendet: Samstag, 21. Januar 2023 06:27
> > > An: dev@tinkerpop.apache.org
> > > Betreff: [VOTE] TinkerPop 3.6.2 Release
> > >
> > > Hello,
> > >
> > > We are happy to announce that TinkerPop 3.6.2 is ready for release.
> > >
> > > The release artifacts can be found at this location:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.6.2/
> > >
> > > The source distribution is provided by:
> > > apache-tinkerpop-3.6.2-src.zip
> > >
> > > Two binary distributions are provided for user convenience:
> > > apache-tinkerpop-gremlin-console-3.6.2-bin.zip
> > > apache-tinkerpop-gremlin-server-3.6.2-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:
> > > https://tinkerpop.apache.org/docs/3.6.2/ (user docs)
> > > https://tinkerpop.apache.org/docs/3.6.2/upgrade/ (upgrade
> docs)
> > > https://tinkerpop.apache.org/javadocs/3.6.2/core/ (core
> javadoc)
> > > https://tinkerpop.apache.org/javadocs/3.6.2/full/ (full
> javadoc)
> > > https://tinkerpop.apache.org/dotnetdocs/3.6.2/ (.NET API docs)
> > > https://tinkerpop.apache.org/jsdocs/3.6.2/ (Javascript API
> docs)
> > >
> > > The Git tag can be found here:
> > > https://github.com/apache/tinkerpop/tree/3.6.2
> > >
> > > The release notes are available here:
> > >
> > https://github.com/apache/tinkerpop/blob/3.6.2/CHANGELOG.asciidoc
> > >
> > > Please note that you may get "rm: cannot remove" permission errors when
> > > running bin/validate-distribution.sh, which we have made a note to fix
> > > after the release. The temporary solution is to run this script with
> sudo
> > > or editing the script to add sudo to "rm" commands.
> > >
> > > The [VOTE] will be open for the next 72 hours --- closing Monday
> (January
> > > 23, 2023) at 9:30pm PST (UTC−08:00).
> > >
> > > My vote is +1.
> > >
> > > Thank you very much,
> > >
> > > Yang Xia
> > > *--*
> > > *Yang Xia*
> > > Software Engineer
> > > Bit Quill Technologies Inc.
> > > ya...@bitquilltech.com
> > > https://www.bitquill.com
> > >
> > > This email message is for the sole use of the intended recipient(s) and
> > > may contain confidential and privileged information.  Any unauthorized
> > > review, use, disclosure, or distribution is prohibited.  If you are not
> > the
> > > intended recipient, please contact the sender by reply email and
> destroy
> > > all copies of the original message.  Thank you.
> > >
> > >
> >
>

Re: [VOTE] TinkerPop 3.5.5 Release

[David Bechberger]

VOTE +1 (non-binding)

Thanks for getting this release out the door.

On Mon, Jan 23, 2023 at 10:29 AM Ken Hu 
wrote:

> Thanks Yang. This looks good to me.
>
> VOTE +1 (non-binding)
>
> On Mon, Jan 23, 2023 at 10:04 AM Cole Greer
>  wrote:
>
> > Thanks for putting this all together Yang. I’ve dug through the docs and
> > artifacts and it all looks good to me.
> >
> > VOTE +1 (non-binding)
> >
> > Regards,
> >
> > Cole Greer
> >
> > From: Valentyn Kahamlyk 
> > Date: Monday, January 23, 2023 at 9:19 AM
> > To: dev@tinkerpop.apache.org 
> > Subject: Re: [VOTE] TinkerPop 3.5.5 Release
> > VOTE +1 (non-binding)
> >
> > On Fri, Jan 20, 2023 at 7:03 AM Florian Hockmann  >
> > wrote:
> >
> > > Thanks a lot for taking care of the releases!
> > >
> > > I checked the links, skimmed over the docs and executed
> > > bin/validate-distribution.sh. This failed for me for some reason. It
> > > complains about a missing Docker image:
> > >
> > > failed to solve: tinkerpop/gremlin-server:3.5.5:
> > > docker.io/tinkerpop/gremlin-server:3.5.5: not found
> > >
> > > but that only happens during validation of the source distribution and
> is
> > > probably specific to my system and not related to this release. The
> other
> > > checks also already passed at that point. So, this shouldn't stop the
> > > release process.
> > >
> > > My vote is +1.
> > >
> > > -Ursprüngliche Nachricht-
> > > Von: Yang Xia 
> > > Gesendet: Donnerstag, 19. Januar 2023 23:13
> > > An: dev@tinkerpop.apache.org
> > > Betreff: [VOTE] TinkerPop 3.5.5 Release
> > >
> > > Hello,
> > >
> > > We are happy to announce that TinkerPop 3.5.5 is ready for release.
> > >
> > > The release artifacts can be found at this location:
> > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.5/
> > >
> > > The source distribution is provided by:
> > > apache-tinkerpop-3.5.5-src.zip
> > >
> > > Two binary distributions are provided for user convenience:
> > > apache-tinkerpop-gremlin-console-3.5.5-bin.zip
> > > apache-tinkerpop-gremlin-server-3.5.5-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:
> > > https://tinkerpop.apache.org/docs/3.5.5/ (user docs)
> > > https://tinkerpop.apache.org/docs/3.5.5/upgrade/ (upgrade
> docs)
> > > https://tinkerpop.apache.org/javadocs/3.5.5/core/ (core
> javadoc)
> > > https://tinkerpop.apache.org/javadocs/3.5.5/full/ (full
> javadoc)
> > > https://tinkerpop.apache.org/dotnetdocs/3.5.5/ (.NET API docs)
> > > https://tinkerpop.apache.org/jsdocs/3.5.5/ (Javascript API
> docs)
> > >
> > > The Git tag can be found here:
> > > https://github.com/apache/tinkerpop/tree/3.5.5
> > >
> > > The release notes are available here:
> > >
> > https://github.com/apache/tinkerpop/blob/3.5.5/CHANGELOG.asciidoc
> > >
> > > Please note that when you run bin/validate-distribution.sh, you might
> get
> > > "rm: cannot remove" permission errors for some GLV test outputs. As
> this
> > > does not affect server/console nor the regular "mvn clean install"
> > > commands, we will not hold the release on that, but have made a note to
> > > fix after the release. The temporary solution is to run this script
> with
> > > sudo or editing the script to add sudo to "rm" commands.
> > >
> > > The [VOTE] will be open for the next 72 hours --- closing Sunday
> (January
> > > 22, 2023) at 2:15pm, PST (UTC−08:00).
> > >
> > > My vote is +1.
> > >
> > > Thank you very much,
> > >
> > > Yang Xia
> > >
> > > *--*
> > > *Yang Xia*
> > > Software Engineer
> > > Bit Quill Technologies Inc.
> > > ya...@bitquilltech.com
> > > https://www.bitquill.com
> > >
> > > This email message is for the sole use of the intended recipient(s) and
> > > may contain confidential and privileged information.  Any unauthorized
> > > review, use, disclosure, or distribution is prohibited.  If you are not
> > the
> > > intended recipient, please contact the sender by reply email and
> destroy
> > > all copies of the original message.  Thank you.
> > >
> > >
> >
>

Re: Properties on elements

[David Bechberger]

I like using the with() approach over a strategy, as I think it will be
more user-friendly and discoverable for customers.

I think my main comments are:

1) Let's keep it simple to start with and just allow "All" or "Tokens".
Custom will lead us down a rabbit hole of how far we want to go with allow
different options per label etc.  We can release with a simple v1 and
gather feedback from users on how/if they need more granularity.
Meanwhile, customers can still get this behavior through the use of the
current steps such as valueMap()
2) I think we should leverage the same tokens as we do with valueMap() to
help show that they are connected.
3) "detach" is not a word that most people would associate with returning
properties.  I suggest something like "materializeProperties"

Combining these together we get the following as the proposed syntax:
g.with(‘materializeProperties’, T.tokens).V()
g.with(‘materializeProperties’, T.all).V()

As far as the default goes, no matter which way we choose, someone will not
be happy.  If we choose to default to "tokens", then we are in the same
behavior as currently, which benefits existing applications while making
new applications unhappy.  If we choose to default to "all", then this may
be a breaking change for applications but will smooth the on ramp for new
customers as the current behavior is unexpected.  Between these two, I
would vote for going with the breaking behavior to simplify the new
developer experience.  While it may break some users, I have not often seen
users returning the elements, as it is usually a combination of just an id
or label explicitly or those tokens with all or a subset of properties.

Another advantage to defaulting to returning all the materialized values is
that this will benefit many visualization tools that need to manually
request this information today to render correctly.

Thoughts?

Dave

On Thu, Dec 8, 2022 at 7:41 AM Stephen Mallette 
wrote:

> i was trying to summarize the decisions we're trying to make on this issue
> and it occurred to me that the problems we're facing here raise some
> fundamental questions about the original direction i'd proposed. i long ago
> chose a strategy approach to doing this, mostly because we have some
> history of doing that with HaltedTraverserStrategy and
> ReferenceElementStrategy, but I can't help wondering now if that pattern
> should be followed. It's troubling me that DetachStrategy,
> ReferenceElementStrategy , etc. really don't have any relevance to embedded
> use cases (aside from the very specific case of OLAP with
> HaltedTraverserStrategy). They are really just mechanisms to help control
> serialization costs and as such are more request/response oriented as
> opposed to traversal oriented. If we treated it that way maybe some of
> these hard decisions would go away.
>
> I was thinking that maybe we could add “detachment” to RequestOptions and
> use the same syntax already established for DetachStrategy in there. Hooked
> up properly this would allow something like:
>
> g.with(‘detach’, Detach.custom("name", "age")).V()
>
> On the server, we’d then just have to extract that Detach from the
> RequestMessage and apply it on serialization as needed.
>
> I see several advantages with this revised design:
>
> 1. No more worries about the extra step in profile() - which is even a
> problem now in ReferenceElementStrategy
> 2. This works as easily for scripts as it does for bytecode
> 3. We don’t mix this capability up with embedded use cases, so there’s no
> confusion about when/why you use this.
>
> Going further with the above Gremlin syntax, maybe the argument to with()
> should be like:
>
> g.with(‘detach’, "ALL").V()
> g.with(‘detach’, "NONE").V()
> g.with(‘detach’, ["name", "age"]).V() // a list implies CUSTOM
>
> The advantage here is that we don’t have to change the grammar in
> gremlin-language and the serializers don’t need to change at all. We could
> retain the Detach.custom("name", "age") or similar syntax for Java/Groovy
> and come up with similar sugar for the other languages.
>
> I think that still leaves the question of what the default should be on the
> server for 3.7.0 - perhaps we come back to that once there is feedback on
> this design revision.
>
>
>
> On Tue, Nov 22, 2022 at 7:06 AM Stephen Mallette 
> wrote:
>
> > > My proposal is to always have some detachment strategy in server
> > configuration and add `DetachedStrategy` to allow users the flexibility
> to
> > customize the result.
> >
> > I think default detachment on the server should remain "reference" so if
> > you can do that with your new DetachStrategy then that is preferred with
> > the idea that HaltedTraverserStrategy is no longer useful and can be
> > deprecated.
> >
> > > How to handle more than one DetachedStrategy?
> >
> > I agree that they shouldn't stack - DetachedStrategy should not be used
> > for some sort of security use case. A client-side one should replace the
> > server-side one.
> >
> 

Re: [DISCUSS] Next releases: 3.5.5 / 3.6.2 / 3.7.0 (?)

[David Bechberger]

I also agree that moving the 3.7 date to 2023 and maintaining the
3.5.5/3.6.2 release branches makes the most sense for where the community
is at.

Dave

On Wed, Nov 23, 2022 at 11:09 AM Ken Hu 
wrote:

> Hi Florian,
>
> I've compiled a list of items in response to your question about open
> issues/PRs that we would want before a 3.5.5/3.6.2 release. They are as
> follows:
>
> Open Issues
> TINKERPOP-2813. This is an important issue for handling NoHostAvailable
> exceptions.
>
> Open Pull Requests
> 1833 (TINKERPOP-2814) Removing default SSL handshake timeout.
> 1838 (TINKERPOP-2480) Adding a User-Agent to the WebSocket handshake.
> 1836 (TINKERPOP-2818) Excluding mockito-core from gremlin-core.
> 1860/1846 Better error messages.
>
> These items should be completed in the coming weeks and so a release can
> still likely be targeted for the end of this year.
>
> Regards,
> Ken
>
>
> On Wed, Nov 23, 2022 at 6:21 AM Jorge Bay Gondra  >
> wrote:
>
> > I agree with moving the target date for 3.7.0 and only releasing 3.5.5
> and
> > 3.6.2 for now.
> >
> >
> > On Wed, Nov 23, 2022 at 12:20 PM Florian Hockmann <
> f...@florian-hockmann.de>
> > wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > our last release was already in July, and I think we now have a lot of
> > > contributions in the dev branches, so I'd like to propose we do a
> release
> > > soon.
> > >
> > >
> > >
> > > Now, the question is: Do we only want to release 3.5.5 and 3.6.2 or do
> we
> > > also already want to release 3.7.0 at this point?
> > >
> > >
> > >
> > > The CHANGELOG for 3.7.0 currently lists a few changes, but I think the
> > only
> > > major change is the added support for mid-traversal E()-steps.[1] Our
> > > current plan for the 3.7.0 release however lists quite a number of
> > features
> > > that we wanted to implement in that version.[2]
> > >
> > > We can now either decide to move the features that are not implemented
> > yet
> > > (and not expected to be implemented in the next few weeks) to version
> > 3.8.0
> > > or not release 3.7.0 at this point and instead move its target release
> > date
> > > to 2023.
> > >
> > >
> > >
> > > If we decide to release 3.7.0 at this point, then we should also
> discuss
> > > whether we want to continue supporting the 3.5 line or making 3.5.5 the
> > > last
> > > release. If we want to continue supporting it, then we have 4 active
> dev
> > > branches (3.5-dev, 3.6-dev, 3.7-dev, and master for 3.8.0).
> > >
> > >
> > >
> > > I suggest that we move the target release date for 3.7.0 to 2023 as
> most
> > of
> > > the planned features are not ready yet and because most (all?) graph
> > > providers haven't even updated to 3.6 yet which also means that we
> > probably
> > > want to continue supporting 3.5. Having to support 4 branches however
> > adds
> > > some burden to our development workflow.
> > >
> > > Any thoughts on this?
> > >
> > >
> > >
> > > Now to 3.5.5 and 3.6.2, I think we have quite some contributions ready
> > for
> > > these releases, including some updates that fix security
> vulnerabilities.
> > > Are there any open issues / PRs that should definitely be included in
> > these
> > > releases?
> > >
> > >
> > >
> > > [1]:
> > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/master/CHANGELOG.asciidoc#tinkerpop
> > > -370-release-date-not-officially-released-yet
> > > <
> >
> https://github.com/apache/tinkerpop/blob/master/CHANGELOG.asciidoc#tinkerpop-370-release-date-not-officially-released-yet
> > >
> > >
> > > [2]:
> > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/index.as
> > > ciidoc#37x---target-22q4
> > > <
> >
> https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/index.asciidoc#37x---target-22q4
> > >
> > >
> > >
> >
>

Re: [DISCUSS] Add analytics to project website

[David Bechberger]

+1 to this idea.  Having analytics on what is being viewed would be very
helpful.

Dave

On Thu, Jul 21, 2022 at 12:54 AM Divij Vaidya 
wrote:

> Hey folks
>
> Apache has a self hosted version of Matomo which can provide website
> analytics. This analytics could be useful for making decisions about site
> re-design and content visibility in the future.
>
> When the code change is complete, everyone would be able to track the site
> usage at https://matomo.privacy.apache.org/
>
> I propose that we should add analytics to the project website. What do you
> think?  (If folks agree, I will pick up the work for doing this.)
>
> Regards,
> Divij Vaidya
>

Re: [DISCUSS] hasKey() should throw an error when invoked on Element traverser

[David Bechberger]

Hello Divij,

I added a few comments to the JIRA and agree that the behavior is
inconsistent but have a different proposal.  Let me know what you think?

Dave

On Tue, Feb 22, 2022 at 3:42 AM Divij Vaidya 
wrote:

> Hey folks
>
> I have created a JIRA to modify the behaviour of hasKey() step when invoked
> for traversers of type Element. Please take a look and let me know if I am
> missing anything here wrt semantics of this step. Since it's a breaking
> change, we would want to add it to 3.6.0 only.
>
> JIRA: https://issues.apache.org/jira/browse/TINKERPOP-2710
>
> Regards,
> Divij Vaidya
>

[DISCUSS] call() step for Gremlin extensibility

[David Bechberger]

As part of TINKERPOP-2680 I have gone through the design of what a call()
step might look like to enable an extensibility point within Gremlin for
something similar to a stored procedure.  I've written up the details here:

https://gist.github.com/bechbd/1d0101c24c2ca8c1133b9d27b1a99fcf

Any feedback/thoughts on this before are appreciated be we begin
implementation?

[DISCUSS} String Manipulation Functions

[David Bechberger]

As part of TINKERPOP-2672
 I am proposing
the following string manipulation functions and syntax:

https://gist.github.com/bechbd/6de5d3d81fdb765166e435d961b0ccef

Any feedback/thoughts on this before I begin implementation?

Re: [VOTE] TinkerPop 3.5.2 Release

[David Bechberger]

VOTE +1

On Tue, Jan 11, 2022 at 7:43 AM Øyvind Sæbø  wrote:

> VOTE +1
>
> tir. 11. jan. 2022 kl. 17:14 skrev Jorge Bay Gondra <
> jorgebaygon...@gmail.com>:
>
> > VOTE +1
> >
> > On Tue, Jan 11, 2022 at 4:19 PM Kelvin Lawrence  >
> > wrote:
> >
> > > VOTE +1
> > >
> > > Cheers, Kelvin
> > >
> > >
> > > > On Jan 11, 2022, at 05:39, Stephen Mallette 
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.5.2 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > >https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.2/
> > > >
> > > > The source distribution is provided by:
> > > >apache-tinkerpop-3.5.2-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > >apache-tinkerpop-gremlin-console-3.5.2-bin.zip
> > > >apache-tinkerpop-gremlin-server-3.5.2-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:
> > > >https://tinkerpop.apache.org/docs/3.5.2/ (user docs)
> > > >https://tinkerpop.apache.org/docs/3.5.2/upgrade/ (upgrade
> docs)
> > > >https://tinkerpop.apache.org/javadocs/3.5.2/core/ (core
> > javadoc)
> > > >https://tinkerpop.apache.org/javadocs/3.5.2/full/ (full
> > javadoc)
> > > >https://tinkerpop.apache.org/dotnetdocs/3.5.2/ (.NET API
> docs)
> > > >https://tinkerpop.apache.org/jsdocs/3.5.2/ (Javascript API
> > docs)
> > > >
> > > > The tag in Apache Git can be found here:
> > > >https://github.com/apache/tinkerpop/tree/3.5.2
> > > >
> > > > The release notes are available here:
> > > >
> > https://github.com/apache/tinkerpop/blob/3.5.2/CHANGELOG.asciidoc
> > > >
> > > > The [VOTE] will be open for the next 72 hours --- closing Friday
> > (January
> > > > 14, 2022) at 6:30am ET.
> > > >
> > > > My vote is +1.
> > >
> > >
> >
>

Re: [DISCUSS] Remove docs from zip distributions

[David Bechberger]

+1 to removing the docs from the zip folder to minimize the download size.

On Mon, Jan 10, 2022 at 7:44 AM Kelvin Lawrence 
wrote:

> If the docs for each release are available elsewhere it would seem
> reasonable to me to remove them from the Gremlin Server zip file to cut
> down the size of the releases which will be a nice win for people making
> forks of the tree.
> CheersKelvin
> On Monday, January 10, 2022, 10:17:46 AM CST, Stephen Mallette <
> spmalle...@gmail.com> wrote:
>
>  As I was working through the release, I noticed that the bulk of our 170Mb
> (which zips to 80Mb) of Gremlin Server zip distribution 50Mb is the docs
> and 94Mb is the javadoc. We have revisited this question in a while so I
> pose it here - is there value to including one or both of those or should
> we remove them to lighten the load?
>

Re: [DISCUSS] Gryo 4.0

[David Bechberger]

+1 on removing Gryo support

It would be great to be able to simplify the serializer story.  Is
Javascript the only language without GraphBinary support now?

Dave

On Mon, Dec 27, 2021 at 11:48 AM Stephen Mallette 
wrote:

> Just to clarify, I think you are suggesting the removal of the remaining
> deprecated GryoMessageSerializer instances thus removing Gryo as a network
> serialization option at 3.6.0. We would retain Gryo as it pertains to being
> a file storage format.
>
> We removed Gryo Lite for 3.6.0, so complete removal isn't too far around
> the corner. I dont think I have any problems with just doing it all for
> 3.6.0. It would continue to simplify the serialization story if it wasn't
> around. If we could then get Javascript on GraphBinary, we could then
> retire typed GraphSON versions and promote a simple GraphSON format for
> HTTP (like GraphSON 1.0).
>
> On Mon, Dec 27, 2021 at 7:56 AM Divij Vaidya 
> wrote:
>
> > I agree about sun setting Gryo perhaps starting with the 3.6.x release.
> >
> > The reasons for removing it from the code base are as follows:
> > 1. Gryo serilization of properties is not consistent with the GraphBinary
> > or Graphson. As an example, Gryo tries to fetch the label of the parent
> > element when serializing a property whereas other serializers only
> provide
> > the ID of the parent element.
> > 2. GraphBinary is a direct replacement with binary serialization support
> > and better performance. GraphBinary support has also been expanded to
> > Python and is the default serializer starting 3.5.x release train.
> >
> > Divij Vaidya
> >
> >
> >
> > On Wed, Aug 26, 2020 at 10:28 AM Stephen Mallette 
> > wrote:
> >
> > > I was just perusing JIRA a bit and came across an item to upgrade to
> Kryo
> > > 4.0 for a performance enhancement:
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP-2398
> > >
> > > As I commented on that issue, which has not yet gotten a response, I
> > > believe that upgrading to Kryo 4.0 breaks binary compatibility with
> Kryo
> > > 3.0 which would mean we would probably need to stamp out Gryo 4.0 as a
> > > result.
> > >
> > > I'm not sure I see the need to produce another version of Gryo as we've
> > > deprecated it in Gremlin Server already and are pushing for wider use
> of
> > > GraphBinary as a replacement for Gryo and GraphSON for network
> > > serialization. I'm not sure where that leaves us with disk
> serialization
> > > but the limitation Gryo has in not working off the JVM hampers it a bit
> > for
> > > what I think of as our current usage these days.
> > >
> > > I'm inclined to continue us on a path to full deprecation of Gryo, even
> > for
> > > disk, in favor of GraphBinary, in which case, I don't think it's in our
> > > interest to introduce Gryo 4.0. Does anyone have any thoughts on this
> > > topic?
> > >
> >
>

Re: [DISCUSS] Geo-Spatial support

[David Bechberger]

Sorry Josh, I just realized I never responded to this and thanks for the
feedback.

The scope for the proposed options are based on what tools like DSE Graph
and Janusgraph support.  I definitely agree that we should make sure that
what we choose is extensible as well as in line with standards.  I am not
too familiar with GeoSPARQL but I have done a lot with WKT format which
does allow for definitions of items like polygons with holes,
muli-polygons, and multipoints that we may want to include at some point.

As far as the initial proposed predicates I was sort of looking at what was
supported by other common indexing backends like Elasticsearch to provide a
glimpse of the most common types of patterns people are searching on.

Dave


On Tue, Aug 3, 2021 at 4:37 AM Stephen Mallette 
wrote:

> Just noticed I hadn't commented on this thread - I'm in favor of this
> addition. Other graphs have already built this sort of functionality and it
> is already satisfying existing use cases so we already have a model for how
> this sort of functionality will work. I'd agree with Josh that there may
> yet be some details on the implementation to consider but I don't have much
> to add to the general proposal Dave has provided. Looks good to me.
>
> On Fri, Jul 23, 2021 at 11:47 AM Joshua Shinavier 
> wrote:
>
> > Hi Dave,
> >
> > I think something like this is a very good idea, and these look like
> useful
> > primitives. IMO when it comes to geospatial queries, the devil is in the
> > details. For example, at some point we'll have someone asking for
> > double-precision lat/lon points (GPS is not that accurate, but some
> > applications use computed/simulated points, or combine GPS data with
> local
> > position). Polygons are sometimes defined as having "holes", etc. It may
> be
> > worthwhile to take some direction from OGC standards like GeoSPARQL.
> >
> > Just an initial $0.02. Ideally, the extension would be simple for
> > developers to use and understand (as this is), while also being somewhat
> > future-proof and playing well with standards.
> >
> > Josh
> >
> >
> >
> > On Thu, Jul 22, 2021 at 2:44 PM David Bechberger 
> > wrote:
> >
> > > One of the common requests from customers and users of TinkerPop is to
> > add
> > > support for geographic based searches (TINKERPOP-2558
> > > <https://issues.apache.org/jira/browse/TINKERPOP-2558>). In fact many
> > > TinkerPop enabled database vendors such as DataStax Graph and
> JanusGraph
> > > have added custom predicates and libraries to handle this request. As a
> > > query language framework it would make sense for TinkerPop to adopt a
> > > common geo-predicate framework to provide standardization across
> > providers
> > > and to support this as part of the TinkerPop ecosystem.
> > >
> > > In consultation with some others on the project we have put together a
> > > proposed scheme for supporting this in TinkerPop which I have
> documented
> > in
> > > a gist here:
> > > https://gist.github.com/bechbd/70f4ce5a537d331929ea01634b1fbaa2
> > >
> > > Interested in hearing others thoughts?
> > >
> > > Dave
> > >
> >
>

[DISCUSS] Proposed Homepage updates

[David Bechberger]

When I was making a few updates to the homepage a little while ago I
noticed that it looked a bit dated and suffered a bit from being a large
wall of text.  I took the liberty of making some tweaks to the styling etc.
and wanted to get feedback on the proposed update.  One important thing to
note is that none of the content was removed, just rearranged.  The use
cases page was added but other than that the content remains the same, just
reorganized.

I have a version up and running on github here: https://bechbd.github.io/

Any thoughts/feedback is appreciated.

Dave

[DISCUSS] Geo-Spatial support

[David Bechberger]

One of the common requests from customers and users of TinkerPop is to add
support for geographic based searches (TINKERPOP-2558
). In fact many
TinkerPop enabled database vendors such as DataStax Graph and JanusGraph
have added custom predicates and libraries to handle this request. As a
query language framework it would make sense for TinkerPop to adopt a
common geo-predicate framework to provide standardization across providers
and to support this as part of the TinkerPop ecosystem.

In consultation with some others on the project we have put together a
proposed scheme for supporting this in TinkerPop which I have documented in
a gist here:
https://gist.github.com/bechbd/70f4ce5a537d331929ea01634b1fbaa2

Interested in hearing others thoughts?

Dave

Re: [VOTE] TinkerPop 3.4.12 Release

[David Bechberger]

+1

On Tue, Jul 20, 2021 at 11:02 AM Stephen Mallette 
wrote:

> Docs look good and validate-distribution.sh passed
>
> VOTE +1
>
> On Tue, Jul 20, 2021 at 5:01 AM Florian Hockmann 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.4.12 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.12/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.4.12-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.4.12-bin.zip
> > apache-tinkerpop-gremlin-server-3.4.12-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:
> > https://tinkerpop.apache.org/docs/3.4.12/ (user docs)
> > https://tinkerpop.apache.org/docs/3.4.12/upgrade/ (upgrade docs)
> > https://tinkerpop.apache.org/javadocs/3.4.12/core/ (core
> javadoc)
> > https://tinkerpop.apache.org/javadocs/3.4.12/full/ (full
> javadoc)
> > https://tinkerpop.apache.org/dotnetdocs/3.4.12/ (.NET API docs)
> > https://tinkerpop.apache.org/jsdocs/3.4.12/ (Javascript API
> docs)
> >
> > The tag in Apache Git can be found here:
> > https://github.com/apache/tinkerpop/tree/3.4.12
> >
> > The release notes are available here:
> >
> https://github.com/apache/tinkerpop/blob/3.4.12/CHANGELOG.asciidoc
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday (July
> 23,
> > 2021) at 10am UTC.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Florian Hockmann
> >
> >
>

Re: [DISCUSS] datetime

[David Bechberger]

+1 from me as well.

On Thu, Jul 22, 2021 at 8:28 AM Kelvin Lawrence 
wrote:

> A big +1 from me for this. As much as possible making Gremlin a language
> that does not depend on closures for things like dates and string
> manipulation will help with parity when compared to other query languages.
> Kelvin
>
>
> On Wednesday, July 21, 2021, 07:49:17 AM CDT, Stephen Mallette <
> spmalle...@gmail.com> wrote:
>
>  One of the things precluding a move toward a more pure usage of
> gremlin-language in place of groovy scripts is a way to instantiate a
> date/time. It seems simple enough to just include a datetime() function in
> the grammar that will parse a ISO-8601 formatted dates:
>
> datetime('2021-07-21')
> datetime('2021-07-21T01:12:59')
> datetime('2021-07-21T01:12:59+0500')
>
> Each language can retain its own method for producing datetime that it
> already has.
>

Re: [DISCUSS] remove groovy from gremlin-driver

[David Bechberger]

Is reason for removing it is that this underlying groovy issue (
https://issues.apache.org/jira/browse/GROOVY-9785) is blocking the upgrade?



On Thu, Jul 22, 2021 at 9:40 AM Stephen Mallette 
wrote:

> In 3.6.0 I think it worth taking the step to remove all groovy dependencies
> from gremlin-driver. They were made  in 3.5.0 and based on there
> being no replies to this query on usage of the feature related to this
> dependency:
>
> https://groups.google.com/g/gremlin-users/c/vFPNwbHFl4w/m/U11fOLhWAgAJ
>
> I think that we can safely remove it. I believe that the impact here is
> only to GraphSON and Gryo. For Gryo, we've already deprecated it as a
> network protocol, but it was already an optional registration so if you
> needed it you could copy/paste the simple bit of code related to it and
> maintain it yourself. For GraphSON, it was made an standard part of the
> GremlinServerModule, but I think like, Gryo it would be easy enough to
> maintain your own custom version.
>
> Created this to track it:
> https://issues.apache.org/jira/browse/TINKERPOP-2593
>
> Please let me know if there are any concerns.
>

Re: [VOTE] TinkerPop 3.5.1 Release

[David Bechberger]

Agreed, thanks for all the hard work.  +1

We should probably include something about Discord in any sort of email
communication as well.

Thanks,
Dave

On Thu, Jul 22, 2021 at 8:27 AM Kelvin Lawrence 
wrote:

> Thanks for all the hard work to get the release out. VOTE +1
> Kelvin
> On Wednesday, July 21, 2021, 01:00:34 PM CDT, Stephen Mallette <
> spmalle...@gmail.com> wrote:
>
>  It was an unfortunate omission but we probably should have had the
> gremlint
> library in the 3.5.1 upgrade docs. oh well, not something to retrigger all
> that work over. Florian, please plan to call attention to it in the release
> announcement in some way. I'll write something to add to the upgrade docs
> for 3.5.1 so it will be there in the future.
>
> Other than that, bin/valdiate-distribution.sh worked fine so VOTE +1
>
> On Wed, Jul 21, 2021 at 10:16 AM Florian Hockmann 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.5.1 is ready for release.
> >
> > The release artifacts can be found at this location:
> >https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.1/
> >
> > The source distribution is provided by:
> >apache-tinkerpop-3.5.1-src.zip
> >
> > Two binary distributions are provided for user convenience:
> >apache-tinkerpop-gremlin-console-3.5.1-bin.zip
> >apache-tinkerpop-gremlin-server-3.5.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:
> >https://tinkerpop.apache.org/docs/3.5.1/ (user docs)
> >https://tinkerpop.apache.org/docs/3.5.1/upgrade/ (upgrade docs)
> >https://tinkerpop.apache.org/javadocs/3.5.1/core/ (core javadoc)
> >https://tinkerpop.apache.org/javadocs/3.5.1/full/ (full javadoc)
> >https://tinkerpop.apache.org/dotnetdocs/3.5.1/ (.NET API docs)
> >https://tinkerpop.apache.org/jsdocs/3.5.1/ (Javascript API docs)
> >
> > The tag in Apache Git can be found here:
> >https://github.com/apache/tinkerpop/tree/3.5.1
> >
> > The release notes are available here:
> >https://github.com/apache/tinkerpop/blob/3.5.1/CHANGELOG.asciidoc
> >
> > The [VOTE] will be open for the next 72 hours --- closing Saturday (July
> > 24,
> > 2021) at 3pm UTC.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Florian Hockmann
> >
> >
>

Re: [DISCUSS] Discord Server?

[David Bechberger]

I have added the links to the homepage and have a PR here:
https://github.com/apache/tinkerpop/pull/1449

Dave

On Tue, Jul 13, 2021 at 6:08 AM Stephen Mallette 
wrote:

> fwiw, I've not had any problems with it. assuming there isn't a problem for
> others, i'm inclined to say we move forward with it.
>
> dave, perhaps you could submit a PR (master branch) to update the website
> to include a link to the channel? I'd add it to the Community navigation
> menu dropdown here:
>
>
> https://github.com/apache/tinkerpop/blob/master/docs/site/home/template/header-footer.html
>
> and to the "Contributing to Apache TinkerPop" section on item 1 of the home
> page ("Join the Gremlin-Users public mailing list and Discord"):
>
> https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html
>
> There might be other places too but those immediately came to mind.
>
> Perhaps for a while it could also be added to the home page (index.html)
> somewhere? a small banner at the top (below the navigation) of some sort to
> call attention to it? If we can get that PR merged in the next week that
> will allow the change to publish when florian completes the release.
>
>
>
>
>
>
> On Mon, Jul 12, 2021 at 7:06 PM Joshua Shinavier 
> wrote:
>
> > That's the one I keep using! Shrug. If no-one else is having the same
> > problem, then maybe it isn't much of a problem.
> >
> > Josh
> >
> > On Mon, Jul 12, 2021 at 4:03 PM David Bechberger 
> > wrote:
> >
> > > I thought that had been fixed with the new link (
> > > https://discord.gg/ndMpKZcBEE) as the first link I sent allows you to
> > > "Preview" which causes the behavior you mentioned.
> > >
> > > Josh, is the link above the one you are using when you see the issue?
> > >
> > > Dave
> > >
> > > On Mon, Jul 12, 2021 at 2:08 PM Joshua Shinavier 
> > > wrote:
> > >
> > > > Maybe I'm the only one, but every time I open up Discord after a few
> > > days,
> > > > I no longer see the Gremlin Icon for the Apache TinkerPop server, and
> > > have
> > > > to find and click your invite link all over again. Discord then
> > > "welcomes"
> > > > me into the #general channel. Might just be my inexperience with
> > > Discord; I
> > > > haven't used it yet for anything else.
> > > >
> > > > Josh
> > > >
> > > >
> > > > On Mon, Jul 12, 2021 at 1:39 PM David Bechberger <
> d...@bechberger.com>
> > > > wrote:
> > > >
> > > > > Now that we have a month+ of using Discord I was wondering what
> > > people's
> > > > > thoughts were on opening membership up to the Gremlin-users list
> and
> > > > > including it on the website?
> > > > >
> > > > > On Thu, May 27, 2021 at 9:22 AM David Bechberger <
> > d...@bechberger.com>
> > > > > wrote:
> > > > >
> > > > > > So one of the things I have seen so far is that the original
> link I
> > > > sent
> > > > > > allowed users to "Preview" the server which allows you to see the
> > > > > channels
> > > > > > and post but as soon as you log off you are removed from the
> > server.
> > > > > > Several people seem to have run into this so I have created a new
> > > link
> > > > > > below which does not allow this type of "Preview".
> > > > > >
> > > > > > https://discord.gg/ndMpKZcBEE
> > > > > >
> > > > > > Dave
> > > > > >
> > > > > > On Mon, May 24, 2021 at 12:05 PM David Bechberger <
> > > d...@bechberger.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> I agree, I think fewer channels is better to start with.  If we
> > get
> > > > to a
> > > > > >> level where the activity level is high we can always add
> > additional
> > > > > >> channels.
> > > > > >>
> > > > > >>
> > > > > >> On Fri, May 21, 2021 at 9:54 AM Stephen Mallette <
> > > > spmalle...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> thanks dave. I imagine the available channels are up for
> > > discussion.
> > > &g

Re: [DISCUSS] Discord Server?

[David Bechberger]

I thought that had been fixed with the new link (
https://discord.gg/ndMpKZcBEE) as the first link I sent allows you to
"Preview" which causes the behavior you mentioned.

Josh, is the link above the one you are using when you see the issue?

Dave

On Mon, Jul 12, 2021 at 2:08 PM Joshua Shinavier  wrote:

> Maybe I'm the only one, but every time I open up Discord after a few days,
> I no longer see the Gremlin Icon for the Apache TinkerPop server, and have
> to find and click your invite link all over again. Discord then "welcomes"
> me into the #general channel. Might just be my inexperience with Discord; I
> haven't used it yet for anything else.
>
> Josh
>
>
> On Mon, Jul 12, 2021 at 1:39 PM David Bechberger 
> wrote:
>
> > Now that we have a month+ of using Discord I was wondering what people's
> > thoughts were on opening membership up to the Gremlin-users list and
> > including it on the website?
> >
> > On Thu, May 27, 2021 at 9:22 AM David Bechberger 
> > wrote:
> >
> > > So one of the things I have seen so far is that the original link I
> sent
> > > allowed users to "Preview" the server which allows you to see the
> > channels
> > > and post but as soon as you log off you are removed from the server.
> > > Several people seem to have run into this so I have created a new link
> > > below which does not allow this type of "Preview".
> > >
> > > https://discord.gg/ndMpKZcBEE
> > >
> > > Dave
> > >
> > > On Mon, May 24, 2021 at 12:05 PM David Bechberger  >
> > > wrote:
> > >
> > >> I agree, I think fewer channels is better to start with.  If we get
> to a
> > >> level where the activity level is high we can always add additional
> > >> channels.
> > >>
> > >>
> > >> On Fri, May 21, 2021 at 9:54 AM Stephen Mallette <
> spmalle...@gmail.com>
> > >> wrote:
> > >>
> > >>> thanks dave. I imagine the available channels are up for discussion.
> to
> > >>> start, i'd think the fewer channels the better. should we already be
> > >>> looking to peel off into different graph provider channels?
> > >>>
> > >>> On Fri, May 21, 2021 at 1:14 PM David Bechberger <
> d...@bechberger.com>
> > >>> wrote:
> > >>>
> > >>> > I've gone ahead and set up a Discord instance for us to try.
> > >>> >
> > >>> > My thinking is that we can try this out internally for a week or
> two
> > >>> and
> > >>> > then, if we like it, we promote this to the larger community.
> > >>> Thoughts?
> > >>> >
> > >>> > If you click on the link below it should allow anyone here to join:
> > >>> > https://discord.gg/5a72PZgmdq
> > >>> >
> > >>> >
> > >>> > On Fri, May 14, 2021 at 2:17 AM Stephen Mallette <
> > spmalle...@gmail.com
> > >>> >
> > >>> > wrote:
> > >>> >
> > >>> > > We've not promoted Slack as a place for users (purposefully). I'd
> > say
> > >>> > it's
> > >>> > > worth adding Discord and giving it a shot for the user community
> > and
> > >>> > > keeping slack for those few moments where we need to ping each
> > other
> > >>> for
> > >>> > > dev related items that might need some quick back/forth
> > interaction.
> > >>> > >
> > >>> > > On Thu, May 13, 2021 at 9:14 PM Joshua Shinavier <
> > j...@fortytwo.net>
> > >>> > > wrote:
> > >>> > >
> > >>> > > > I haven't used Discord much myself, but I don't see the down
> side
> > >>> of
> > >>> > > trying
> > >>> > > > it out amongst ourselves, then inviting a few community
> members.
> > >>> If the
> > >>> > > > response is positive, announce it on gremlin-users. We already
> > >>> have a
> > >>> > > Slack
> > >>> > > > workspace which is not much used, so in the worst case, now
> there
> > >>> are
> > >>> > > two.
> > >>> > > >
> > >>> > > > ^^ $0.02
> > >>> > > >
> > >>> > > > On Wed, May 12, 2021 at 4:53 PM David Bechberger <
> > >>> d...@bechberger.com>
> > >>> > > > wrote:
> > >>> > > >
> > >>> > > > > With the recent uptick in both StackOverflow posts and
> mailing
> > >>> list
> > >>> > > > posts,
> > >>> > > > > it has got me thinking about ways to get more users engaged
> > with
> > >>> the
> > >>> > > > > TinkerPop community. I was curious what people's thoughts
> were
> > on
> > >>> > > > starting
> > >>> > > > > a Discord server?
> > >>> > > > >
> > >>> > > > > The pros I see here are:
> > >>> > > > >
> > >>> > > > > * The ability to interact with users directly
> > >>> > > > > * The ability (through bots) to create a single location to
> > >>> monitor
> > >>> > for
> > >>> > > > > questions
> > >>> > > > > * The ability to have statistics on user engagement
> > >>> > > > > * The ability to promote TinkerPop on internal/external
> discord
> > >>> > server
> > >>> > > > > lists
> > >>> > > > >
> > >>> > > > > The biggest con I can think of is that if there is not much
> > >>> usage of
> > >>> > > it,
> > >>> > > > > then it would look like the project was not an active
> > community.
> > >>> > > > >
> > >>> > > > > Thoughts?
> > >>> > > > >
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >>
> >
>

Re: [DISCUSS] Discord Server?

[David Bechberger]

Now that we have a month+ of using Discord I was wondering what people's
thoughts were on opening membership up to the Gremlin-users list and
including it on the website?

On Thu, May 27, 2021 at 9:22 AM David Bechberger 
wrote:

> So one of the things I have seen so far is that the original link I sent
> allowed users to "Preview" the server which allows you to see the channels
> and post but as soon as you log off you are removed from the server.
> Several people seem to have run into this so I have created a new link
> below which does not allow this type of "Preview".
>
> https://discord.gg/ndMpKZcBEE
>
> Dave
>
> On Mon, May 24, 2021 at 12:05 PM David Bechberger 
> wrote:
>
>> I agree, I think fewer channels is better to start with.  If we get to a
>> level where the activity level is high we can always add additional
>> channels.
>>
>>
>> On Fri, May 21, 2021 at 9:54 AM Stephen Mallette 
>> wrote:
>>
>>> thanks dave. I imagine the available channels are up for discussion. to
>>> start, i'd think the fewer channels the better. should we already be
>>> looking to peel off into different graph provider channels?
>>>
>>> On Fri, May 21, 2021 at 1:14 PM David Bechberger 
>>> wrote:
>>>
>>> > I've gone ahead and set up a Discord instance for us to try.
>>> >
>>> > My thinking is that we can try this out internally for a week or two
>>> and
>>> > then, if we like it, we promote this to the larger community.
>>> Thoughts?
>>> >
>>> > If you click on the link below it should allow anyone here to join:
>>> > https://discord.gg/5a72PZgmdq
>>> >
>>> >
>>> > On Fri, May 14, 2021 at 2:17 AM Stephen Mallette >> >
>>> > wrote:
>>> >
>>> > > We've not promoted Slack as a place for users (purposefully). I'd say
>>> > it's
>>> > > worth adding Discord and giving it a shot for the user community and
>>> > > keeping slack for those few moments where we need to ping each other
>>> for
>>> > > dev related items that might need some quick back/forth interaction.
>>> > >
>>> > > On Thu, May 13, 2021 at 9:14 PM Joshua Shinavier 
>>> > > wrote:
>>> > >
>>> > > > I haven't used Discord much myself, but I don't see the down side
>>> of
>>> > > trying
>>> > > > it out amongst ourselves, then inviting a few community members.
>>> If the
>>> > > > response is positive, announce it on gremlin-users. We already
>>> have a
>>> > > Slack
>>> > > > workspace which is not much used, so in the worst case, now there
>>> are
>>> > > two.
>>> > > >
>>> > > > ^^ $0.02
>>> > > >
>>> > > > On Wed, May 12, 2021 at 4:53 PM David Bechberger <
>>> d...@bechberger.com>
>>> > > > wrote:
>>> > > >
>>> > > > > With the recent uptick in both StackOverflow posts and mailing
>>> list
>>> > > > posts,
>>> > > > > it has got me thinking about ways to get more users engaged with
>>> the
>>> > > > > TinkerPop community. I was curious what people's thoughts were on
>>> > > > starting
>>> > > > > a Discord server?
>>> > > > >
>>> > > > > The pros I see here are:
>>> > > > >
>>> > > > > * The ability to interact with users directly
>>> > > > > * The ability (through bots) to create a single location to
>>> monitor
>>> > for
>>> > > > > questions
>>> > > > > * The ability to have statistics on user engagement
>>> > > > > * The ability to promote TinkerPop on internal/external discord
>>> > server
>>> > > > > lists
>>> > > > >
>>> > > > > The biggest con I can think of is that if there is not much
>>> usage of
>>> > > it,
>>> > > > > then it would look like the project was not an active community.
>>> > > > >
>>> > > > > Thoughts?
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] Discord Server?

[David Bechberger]

So one of the things I have seen so far is that the original link I sent
allowed users to "Preview" the server which allows you to see the channels
and post but as soon as you log off you are removed from the server.
Several people seem to have run into this so I have created a new link
below which does not allow this type of "Preview".

https://discord.gg/ndMpKZcBEE

Dave

On Mon, May 24, 2021 at 12:05 PM David Bechberger 
wrote:

> I agree, I think fewer channels is better to start with.  If we get to a
> level where the activity level is high we can always add additional
> channels.
>
>
> On Fri, May 21, 2021 at 9:54 AM Stephen Mallette 
> wrote:
>
>> thanks dave. I imagine the available channels are up for discussion. to
>> start, i'd think the fewer channels the better. should we already be
>> looking to peel off into different graph provider channels?
>>
>> On Fri, May 21, 2021 at 1:14 PM David Bechberger 
>> wrote:
>>
>> > I've gone ahead and set up a Discord instance for us to try.
>> >
>> > My thinking is that we can try this out internally for a week or two and
>> > then, if we like it, we promote this to the larger community.  Thoughts?
>> >
>> > If you click on the link below it should allow anyone here to join:
>> > https://discord.gg/5a72PZgmdq
>> >
>> >
>> > On Fri, May 14, 2021 at 2:17 AM Stephen Mallette 
>> > wrote:
>> >
>> > > We've not promoted Slack as a place for users (purposefully). I'd say
>> > it's
>> > > worth adding Discord and giving it a shot for the user community and
>> > > keeping slack for those few moments where we need to ping each other
>> for
>> > > dev related items that might need some quick back/forth interaction.
>> > >
>> > > On Thu, May 13, 2021 at 9:14 PM Joshua Shinavier 
>> > > wrote:
>> > >
>> > > > I haven't used Discord much myself, but I don't see the down side of
>> > > trying
>> > > > it out amongst ourselves, then inviting a few community members. If
>> the
>> > > > response is positive, announce it on gremlin-users. We already have
>> a
>> > > Slack
>> > > > workspace which is not much used, so in the worst case, now there
>> are
>> > > two.
>> > > >
>> > > > ^^ $0.02
>> > > >
>> > > > On Wed, May 12, 2021 at 4:53 PM David Bechberger <
>> d...@bechberger.com>
>> > > > wrote:
>> > > >
>> > > > > With the recent uptick in both StackOverflow posts and mailing
>> list
>> > > > posts,
>> > > > > it has got me thinking about ways to get more users engaged with
>> the
>> > > > > TinkerPop community. I was curious what people's thoughts were on
>> > > > starting
>> > > > > a Discord server?
>> > > > >
>> > > > > The pros I see here are:
>> > > > >
>> > > > > * The ability to interact with users directly
>> > > > > * The ability (through bots) to create a single location to
>> monitor
>> > for
>> > > > > questions
>> > > > > * The ability to have statistics on user engagement
>> > > > > * The ability to promote TinkerPop on internal/external discord
>> > server
>> > > > > lists
>> > > > >
>> > > > > The biggest con I can think of is that if there is not much usage
>> of
>> > > it,
>> > > > > then it would look like the project was not an active community.
>> > > > >
>> > > > > Thoughts?
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] Discord Server?

[David Bechberger]

I agree, I think fewer channels is better to start with.  If we get to a
level where the activity level is high we can always add additional
channels.


On Fri, May 21, 2021 at 9:54 AM Stephen Mallette 
wrote:

> thanks dave. I imagine the available channels are up for discussion. to
> start, i'd think the fewer channels the better. should we already be
> looking to peel off into different graph provider channels?
>
> On Fri, May 21, 2021 at 1:14 PM David Bechberger 
> wrote:
>
> > I've gone ahead and set up a Discord instance for us to try.
> >
> > My thinking is that we can try this out internally for a week or two and
> > then, if we like it, we promote this to the larger community.  Thoughts?
> >
> > If you click on the link below it should allow anyone here to join:
> > https://discord.gg/5a72PZgmdq
> >
> >
> > On Fri, May 14, 2021 at 2:17 AM Stephen Mallette 
> > wrote:
> >
> > > We've not promoted Slack as a place for users (purposefully). I'd say
> > it's
> > > worth adding Discord and giving it a shot for the user community and
> > > keeping slack for those few moments where we need to ping each other
> for
> > > dev related items that might need some quick back/forth interaction.
> > >
> > > On Thu, May 13, 2021 at 9:14 PM Joshua Shinavier 
> > > wrote:
> > >
> > > > I haven't used Discord much myself, but I don't see the down side of
> > > trying
> > > > it out amongst ourselves, then inviting a few community members. If
> the
> > > > response is positive, announce it on gremlin-users. We already have a
> > > Slack
> > > > workspace which is not much used, so in the worst case, now there are
> > > two.
> > > >
> > > > ^^ $0.02
> > > >
> > > > On Wed, May 12, 2021 at 4:53 PM David Bechberger <
> d...@bechberger.com>
> > > > wrote:
> > > >
> > > > > With the recent uptick in both StackOverflow posts and mailing list
> > > > posts,
> > > > > it has got me thinking about ways to get more users engaged with
> the
> > > > > TinkerPop community. I was curious what people's thoughts were on
> > > > starting
> > > > > a Discord server?
> > > > >
> > > > > The pros I see here are:
> > > > >
> > > > > * The ability to interact with users directly
> > > > > * The ability (through bots) to create a single location to monitor
> > for
> > > > > questions
> > > > > * The ability to have statistics on user engagement
> > > > > * The ability to promote TinkerPop on internal/external discord
> > server
> > > > > lists
> > > > >
> > > > > The biggest con I can think of is that if there is not much usage
> of
> > > it,
> > > > > then it would look like the project was not an active community.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Discord Server?

[David Bechberger]

I've gone ahead and set up a Discord instance for us to try.

My thinking is that we can try this out internally for a week or two and
then, if we like it, we promote this to the larger community.  Thoughts?

If you click on the link below it should allow anyone here to join:
https://discord.gg/5a72PZgmdq


On Fri, May 14, 2021 at 2:17 AM Stephen Mallette 
wrote:

> We've not promoted Slack as a place for users (purposefully). I'd say it's
> worth adding Discord and giving it a shot for the user community and
> keeping slack for those few moments where we need to ping each other for
> dev related items that might need some quick back/forth interaction.
>
> On Thu, May 13, 2021 at 9:14 PM Joshua Shinavier 
> wrote:
>
> > I haven't used Discord much myself, but I don't see the down side of
> trying
> > it out amongst ourselves, then inviting a few community members. If the
> > response is positive, announce it on gremlin-users. We already have a
> Slack
> > workspace which is not much used, so in the worst case, now there are
> two.
> >
> > ^^ $0.02
> >
> > On Wed, May 12, 2021 at 4:53 PM David Bechberger 
> > wrote:
> >
> > > With the recent uptick in both StackOverflow posts and mailing list
> > posts,
> > > it has got me thinking about ways to get more users engaged with the
> > > TinkerPop community. I was curious what people's thoughts were on
> > starting
> > > a Discord server?
> > >
> > > The pros I see here are:
> > >
> > > * The ability to interact with users directly
> > > * The ability (through bots) to create a single location to monitor for
> > > questions
> > > * The ability to have statistics on user engagement
> > > * The ability to promote TinkerPop on internal/external discord server
> > > lists
> > >
> > > The biggest con I can think of is that if there is not much usage of
> it,
> > > then it would look like the project was not an active community.
> > >
> > > Thoughts?
> > >
> >
>

[DISCUSS] Discord Server?

[David Bechberger]

With the recent uptick in both StackOverflow posts and mailing list posts,
it has got me thinking about ways to get more users engaged with the
TinkerPop community. I was curious what people's thoughts were on starting
a Discord server?

The pros I see here are:

* The ability to interact with users directly
* The ability (through bots) to create a single location to monitor for
questions
* The ability to have statistics on user engagement
* The ability to promote TinkerPop on internal/external discord server lists

The biggest con I can think of is that if there is not much usage of it,
then it would look like the project was not an active community.

Thoughts?

Re: [VOTE] TinkerPop 3.4.11 Release

[David Bechberger]

+1

On Thu, May 6, 2021 at 5:53 AM Joshua Shinavier  wrote:

> +1
>
> On Thu, May 6, 2021 at 6:07 AM Øyvind Sæbø  wrote:
>
> > VOTE +1
> >
> > tor. 6. mai 2021 kl. 14:51 skrev Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > >:
> >
> > > VOTE +1
> > >
> > > On Wed, May 5, 2021 at 11:10 AM  wrote:
> > >
> > > > I mostly reviewed the docs and all looks good.
> > > >
> > > > VOTE +1
> > > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Stephen Mallette 
> > > > Gesendet: Dienstag, 4. Mai 2021 18:00
> > > > An: dev@tinkerpop.apache.org
> > > > Betreff: [VOTE] TinkerPop 3.4.11 Release
> > > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.4.11 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.11/
> > > >
> > > > The source distribution is provided by:
> > > > apache-tinkerpop-3.4.11-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > > apache-tinkerpop-gremlin-console-3.4.11-bin.zip
> > > > apache-tinkerpop-gremlin-server-3.4.11-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:
> > > > https://tinkerpop.apache.org/docs/3.4.11/ (user docs)
> > > > https://tinkerpop.apache.org/docs/3.4.11/upgrade/ (upgrade
> > docs)
> > > > https://tinkerpop.apache.org/javadocs/3.4.11/core/ (core
> > > javadoc)
> > > > https://tinkerpop.apache.org/javadocs/3.4.11/full/ (full
> > > javadoc)
> > > > https://tinkerpop.apache.org/dotnetdocs/3.4.11/ (.NET API
> > docs)
> > > > https://tinkerpop.apache.org/jsdocs/3.4.11/ (Javascript API
> > > docs)
> > > >
> > > > The tag in Apache Git can be found here:
> > > > https://github.com/apache/tinkerpop/tree/3.4.11
> > > >
> > > > The release notes are available here:
> > > >
> > > https://github.com/apache/tinkerpop/blob/3.4.11/CHANGELOG.asciidoc
> > > >
> > > > The [VOTE] will be open for the next 72 hours --- closing Friday (May
> > 7,
> > > > 2021) at 12pm ET.
> > > >
> > > > My vote is +1.
> > > >
> > > >
> > >
> >
>

Re: [VOTE] TinkerPop 3.5.0 Release

[David Bechberger]

+1

Really looking forward to this release.

On Thu, May 6, 2021 at 5:47 AM Joshua Shinavier  wrote:

> Awesome. +1
>
> On Thu, May 6, 2021 at 6:42 AM Øyvind Sæbø  wrote:
>
> > 
> >
> > VOTE +1
> >
> > tor. 6. mai 2021 kl. 14:51 skrev Jorge Bay Gondra <
> > jorgebaygon...@gmail.com
> > >:
> >
> > > Yay! 3.5.0!
> > >
> > > VOTE +1
> > >
> > > On Thu, May 6, 2021 at 10:08 AM  wrote:
> > >
> > > > VOTE +1
> > > >
> > > > One small issue I found while reviewing the upgrade docs though:
> > > > TINKERPOP-2317 removed support for Python lambdas in Gremlin Server,
> > but
> > > > Gremlin.Net still supports sending them. This is also documented in
> the
> > > > reference docs:
> > > >
> > https://tinkerpop.apache.org/docs/3.5.0/reference/#gremlin-dotnet-lambda
> > > > I unfortunately completely missed that until now, but I think that
> it's
> > > > not a big issue that we can also fix for 3.5.1. This should
> definitely
> > > not
> > > > stop the release in my opinion.
> > > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Stephen Mallette 
> > > > Gesendet: Mittwoch, 5. Mai 2021 22:50
> > > > An: dev@tinkerpop.apache.org
> > > > Betreff: [VOTE] TinkerPop 3.5.0 Release
> > > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.5.0 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.5.0/
> > > >
> > > > The source distribution is provided by:
> > > > apache-tinkerpop-3.5.0-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > > apache-tinkerpop-gremlin-console-3.5.0-bin.zip
> > > > apache-tinkerpop-gremlin-server-3.5.0-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:
> > > > https://tinkerpop.apache.org/docs/3.5.0/ (user docs)
> > > > https://tinkerpop.apache.org/docs/3.5.0/upgrade/ (upgrade
> > docs)
> > > > https://tinkerpop.apache.org/javadocs/3.5.0/core/ (core
> > javadoc)
> > > > https://tinkerpop.apache.org/javadocs/3.5.0/full/ (full
> > javadoc)
> > > > https://tinkerpop.apache.org/dotnetdocs/3.5.0/ (.NET API
> docs)
> > > > https://tinkerpop.apache.org/jsdocs/3.5.0/ (Javascript API
> > docs)
> > > >
> > > > The tag in Apache Git can be found here:
> > > > https://github.com/apache/tinkerpop/tree/3.5.0
> > > >
> > > > The release notes are available here:
> > > >
> > > https://github.com/apache/tinkerpop/blob/3.5.0/CHANGELOG.asciidoc
> > > >
> > > > The [VOTE] will be open for the next 72 hours --- closing Saturday
> (May
> > > 8,
> > > > 2021) at 5pm ET.
> > > >
> > > > My vote is +1.
> > > >
> > > >
> > >
> >
>

Re: 3.5.0 Announcement Volunteers

[David Bechberger]

I can write a post about the changes in how null is handled.

Dave

On Fri, Apr 30, 2021 at 6:20 AM Øyvind Sæbø  wrote:

> I can write a post about the introduction of Gremlint to TinkerPop and its
> future possibilities.
>
> fre. 30. apr. 2021 kl. 15:55 skrev Marko Rodriguez :
>
> > Hello mein freunden,
> >
> > I’d love to contribute a body of work from mm-ADT that is one of the main
> > issues with the Gremlin language: every step should support pipeline
> > arguments (i.e., every argument can be a dynamically/traversal determined
> > value). I solved this problem in mm-ADT elegantly and efficiently. A
> > beautiful feature indeed.
> >
> > ….unfortunately, Apache Board overruled the TinkerPop PMC and had me
> > forcefully removed from the PMC for being (how do you say in American
> > English?) “Nazi Troll.” If the Board is willing to look past the SS on my
> > uniform and put me back in my rightful place as Obergruppenführer of the
> > PMC, then we shall be unstoppable!
> >
> > Those are my terms. Boohaha.
> >
> > Marko.
> >
> > > On Apr 30, 2021, at 7:34 AM, Stephen Mallette 
> > wrote:
> > >
> > > Wow, this is great - lots of volunteers! Here's a running list of what
> we
> > > have so far:
> > >
> > > * UnifiedChannelizer - Stephen
> > > * gremlin-language - Josh
> > > * Gremlin.Net - Florian
> > > * gremlin-python - Kelvin
> > >
> > > There's definitely a lot more topics to tackle. Let's keep expanding
> the
> > > list.
> > >
> > >
> > >
> > > On Fri, Apr 30, 2021 at 9:27 AM Kelvin Lawrence
>  > >
> > > wrote:
> > >
> > >> I am happy to help. The area I have been closest too is probably the
> > >> enhancements to the Python client. I could write something around
> those
> > >> features.
> > >>
> > >> Cheers, Kelvin
> > >>
> > >>> On Apr 30, 2021, at 04:30, f...@florian-hockmann.de wrote:
> > >>>
> > >>> I could write something for .NET. Added GraphBinary support and
> > >> switching the JSON library could be interesting for some Gremlin.Net
> > users.
> > >>>
> > >>> -Ursprüngliche Nachricht-
> > >>> Von: Stephen Mallette 
> > >>> Gesendet: Donnerstag, 29. April 2021 21:32
> > >>> An: dev@tinkerpop.apache.org
> > >>> Betreff: Re: 3.5.0 Announcement Volunteers
> > >>>
> > >>> Right now, I think it's fine for these to just have each person's
> > >> individual style - might make the posts more interesting assuming we
> > get a
> > >> few more volunteers. If you can come up with a neat image that could
> go
> > >> with a tweet to promote the announcement (that we will push through
> the
> > >> TinkerPop account), that would be cool. We've not really come up with
> > >> anything that sort of iconifies the gremlin-language module, so if you
> > feel
> > >> like thinking about that, that would be neat.
> > >>>
> > >>>
> > >>>
> >  On Thu, Apr 29, 2021 at 2:45 PM Joshua Shinavier  >
> > >> wrote:
> > 
> >  Sounds good. I'll write the announcement. If you have thoughts on
> the
> >  format, please feel free to share.
> > 
> >  Josh
> > 
> >  On Thu, Apr 29, 2021 at 10:56 AM Stephen Mallette
> >  
> >  wrote:
> > 
> > > On Thu, Apr 29, 2021 at 1:38 PM Joshua Shinavier <
> j...@fortytwo.net>
> > > wrote:
> > >
> > >> I would be happy to collaborate on gremlin-language if there is
> >  something
> > >> which needs doing.
> > >>
> > >> Josh
> > >>
> > >>
> > > great josh - thanks! The upgrade docs sorta tuck that feature away
> > > in the provider section
> > >
> > >
> > 
> > https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/upgrade/#_gremlin_lan
> >  guage
> > >
> > > because at this point it doesn't have direct user impact, but i
> > > think it might be useful to the community to write something in an
> > > announcement
> >  that
> > > helps describe what this module lays the foundation for. you've had
> > > some interesting ideas in this area that i'm not sure have gotten
> > > outside of
> >  the
> > > dev list as of yet.
> > >
> > 
> > >>>
> > >>
> > >>
> >
> >
>

Re: [DSISCUSS] Remote Transactions

[David Bechberger]

I am in favor of this change as I any idea that unifies the multiple
different ways things work in TP will only make it easier to learn and
adopt.

I don't know that I have enough knowledge of the inner workings of
transactions to know what/if this will cause problems.

Dave

On Wed, Mar 17, 2021 at 12:57 PM Stephen Mallette 
wrote:

> We haven't touched "transactions" since TP3 was originally designed. They
> have remained a feature for embedded use cases even in the face of the rise
> of remote graph use cases and result in major inconsistencies that really
> bother users.
>
> As we close on 3.5.0, I figured that perhaps there was a chance to do
> something radical about transactions. Basically, I'd like transactions to
> work irrespective of remote or embedded usage and for them to have the same
> API when doing so. In mulling it over for the last day or so I had a
> realization that makes me believe that the following is possible:
>
> g = traversal().withEmbedded(graph)
> // or
> g = traversal().withRemote(conn)
> gtx = g.tx().create()
> gtx.addV('person').iterate()
> gtx.addV('software').iterate()
> gtx.close() // alternatively you could explicitly commit() or rollback()
>
> // you could still use g for sessionless, but gtx is "done" after
> // you close so you will need to create() a new gtx instance for a
> // fresh transaction
> assert 2 == g.V().count().next()
>
> Note that the create() method on tx() is the new bit of necessary syntax.
> Technically, it is a do-nothing for embedded mode (and you could skip it
> for thread-local auto-transactions) but all the documentation can be
> shifted so that the API is identical to remote. The change would be
> non-breaking as the embedded transaction approach would remain as it is,
> but would no longer be documented as the preferred approach. Perhaps we
> could one day disallow it but it's a bit of a tangle of ThreadLocal that
> I'm not sure we want to touch in TP3.
>
> What happens behind the scenes of g.tx().create() is that in remote cases
> the RemoteConnection constructs a remote Transaction implementation which
> basically is used to spawn new traversal source instances with a session
> based connections. The remote Transaction object can't support transaction
> listeners or special read-write/close configurations, but I don't think
> that's a problem as those things don't make a lot of sense in remote use
> cases.
>
> From the server perspective, this change would also mean that sessions
> would have to accept bytecode and not just scripts, which technically
> shouldn't be a problem.
>
> One downside at the moment is that i'm thinking mostly in Java at the
> moment. I'm not sure how this all works in other variants just yet, but I'd
> hope to keep similar syntax.
>
> I will keep experimenting tomorrow. If you have any thoughts on the matter,
> I'd be happy to hear them. Thanks!
>

Re: [DISCUSS] Request Retries

[David Bechberger]

I think this would be a great way to allow customers to easily know if an
error was transient and able to be retried or not.

Dave

On Wed, Feb 17, 2021 at 4:06 AM Stephen Mallette 
wrote:

> I created this issue recently:
>
> https://issues.apache.org/jira/browse/TINKERPOP-2517
>
> which discusses adding a new response status code that would let users know
> when it is a good idea to consider a retry of a request. Graph providers
> could use this code to provide a hint when an error is likely resolvable
> with time. Usually, such errors are related to locking on transactions or
> some similar sort of issue. Currently users need to parse error messages to
> determine when best to retry their requests which isn't so nice.
>
> To make this new code easy to use for providers we could provide a specific
> TemporaryException that could be thrown/extended or i suppose a heavier
> approach would be to offer some kind of exception mapping that providers
> could supply to take their custom exceptions and convert them to this form.
> Not sure which we would do, but the main point would be to provide the code
> itself in the protocol itself so that drivers can begin to pick it up.
>
> I think we could add "SERVER_ERROR_TEMPORARY 596" for this purpose. I'd
> imagine it would be safe to even add it to 3.4.11. Thoughts?
>

Re: [VOTE] Accepting the gremlint donation

[David Bechberger]

Vote +1



On Thu, Feb 18, 2021 at 7:42 AM Kelvin Lawrence 
wrote:

> VOTE +1
> Kelvin
> Kelvin R. Lawrence
>
> On Thursday, February 18, 2021, 08:17:41 AM CST, Stephen Mallette <
> spmalle...@gmail.com> wrote:
>
>  whoa! Dylan Millikin! nice to see you back on the list.
>
> On Thu, Feb 18, 2021 at 8:44 AM Dylan Millikin 
> wrote:
>
> > 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: [DISCUSS] Adding motif support to match()

[David Bechberger]

Thanks for the great feedback.  In general, it seems like there is a lot of
positive feedback on this idea and that it should be a separate from the
existing match() step.

I think there is one detail of my initial proposal that should probably be
clarified.  In my initial proposal I wasn't thinking about adding the
entirety of openCypher/Cypher syntax to Gremlin.  Instead, I was
just thinking of adding the ASCII art portion of it.  If we only go with
ASCII art portion, then I would be hesitant to use the cypher() step as
that would potentially imply more functionality than available.

It seems like there are a few questions we need to decide:

* Do we want to support more than just ASCII Art from cypher/openCypher?
* For the ASCII art do we want to take more of the approach of
cypher/openCypher or the graphX approach to adding filtering:
Examples (ignore the step name it's a placeholder)

Question: Find me all Companies within one hop of a Person vertex with a
name of Dave with an employed_at edge

openCypher/Cypher syntax:
g.V().hasPattern("(p:Person {name: 'Dave'})-[e:employed_at]->(c:Company)")

GraphX style syntax:

g.V().hasPattern("(p)-[e]->(c)",
__.as('p').has('Person', 'name', 'Dave'),
__.as('e').hasLabel('employed_at'),
__.as('c').hasLabel('Company'),
)

Thoughts on these questions?

Dave

On Fri, Feb 5, 2021 at 4:36 AM Josh Perryman  wrote:

> I do like the approach of formally including openCypher / ASCII art into
> Gremlin / TinkerPop. I'm reluctant to overload the match() step for that
> purpose.
>
> The match() step does have a similar purpose, but it has a fraught history.
> I think it would work better from a number of angles to leave it as it is.
>
> I'm more aligned with Joshua's recommendation. The use of the cypher()
> step  (or perhaps an openCypher() step?) makes explicit the transition to
> another language and processing approach.  This pairs nicely with the
> sparql() step and provides an intuitive pattern to introduce other data
> querying approaches ( sql(), gql(), prolog(), mmADT(), pigeon(), ... ).
>
> I do rather like the idea of the overloads within the step, ways to "hook"
> the Gremlin into whatever the query language is. That could provide
> remarkable flexibility and opens up a whole suite of capabilities.
>
> Overall, this is a really great idea which should help with
> interoperability between TinkerPop and other graph frameworks.
>
> Josh
>
>
> On Thu, Feb 4, 2021 at 10:30 PM pieter gmail 
> wrote:
>
> > +1
> >
> > Cheers
> > Pieter
> >
> > On Thu, 2021-02-04 at 17:15 -0800, Joshua Shinavier wrote:
> > > Initial thought: if the ASCII art syntax is Cypher-like, why not make
> > > it
> > > openCypher proper? I.e. keep match() as it is, but generalize the
> > > cypher()
> > > step out of Neo4jGraph, with native Neo4j evaluation of Cypher as an
> > > optimization.
> > >
> > > Josh
> > >
> > >
> > > On Thu, Feb 4, 2021 at 2:17 PM David Bechberger 
> > > wrote:
> > >
> > > > Over the years of working with Gremlin I have foudn the match()
> > > > step is
> > > > difficult to create traversals with and even more difficult to make
> > > > it work
> > > > efficently.  While the imperative style of programming in Gremlin
> > > > provides
> > > > a powerful path finding mechanism it really lacks an easy way to
> > > > perform
> > > > pattern matching queries.  It would be great if we could simplify
> > > > the
> > > > match() step to enable users to easily generate these pattern
> > > > matching
> > > > traversals.
> > > >
> > > > To accomplish this I was wondering what adding support for a subset
> > > > of
> > > > motif/ascii art patterns to the match step might look like.  These
> > > > types of
> > > > patterns are very easy for people to understand and I think the
> > > > ability to
> > > > combine these pattern matching syntax with the powerful path
> > > > finding and
> > > > formatting features of Gremlin would make a powerful combination.
> > > >
> > > > To accomplish this I am suggesting supporting a subset of potential
> > > > patterns.  The two most common examples of this sort of pattern out
> > > > there
> > > > are the openCypher type style and the style used by GraphX.  I have
> > > > provided a few examples below of what this syntax might look like:
> > > >
> > > > e.g. openCypher style
> > > >
> > &g

[DISCUSS] Adding motif support to match()

[David Bechberger]

Over the years of working with Gremlin I have foudn the match() step is
difficult to create traversals with and even more difficult to make it work
efficently.  While the imperative style of programming in Gremlin provides
a powerful path finding mechanism it really lacks an easy way to perform
pattern matching queries.  It would be great if we could simplify the
match() step to enable users to easily generate these pattern matching
traversals.

To accomplish this I was wondering what adding support for a subset of
motif/ascii art patterns to the match step might look like.  These types of
patterns are very easy for people to understand and I think the ability to
combine these pattern matching syntax with the powerful path finding and
formatting features of Gremlin would make a powerful combination.

To accomplish this I am suggesting supporting a subset of potential
patterns.  The two most common examples of this sort of pattern out there
are the openCypher type style and the style used by GraphX.  I have
provided a few examples below of what this syntax might look like:

e.g. openCypher style

Find me everything within one hop
g.V().match("()-[]->()")

Find me everything within one hop of a Person vertex
g.V().match("(p:Person)-[]->()")

Find me all Companies within one hop of a Person vertex
g.V().match("(p:Person)-[]->(c:Company)")

Find me all Companies within one hop of a Person vertex with an Employed_at
edge
g.V().match("(p:Person)-[e:employed_at]->(c:Company)")


The other option would be to take more of a hybrid approach and use only
the basic art/motifs like GraphX and apply the additional filtering in a
hybrid type of mode like this:

Find me all Companies within one hop of a Person vertex with an Employed_at
edge
g.V().match("(p)-[e]->(c)",
__.as('p').hasLabel('Person'),
__.as('e').hasLabel('employed_at'),
__.as('c').hasLabel('Company'),
)

This also has the potential to enable some significantly more complex
patterns like "Find me all Companies within one hop of a Person vertex with
an Employed_at edge who also worked at Foo"
g.V().match("(p)-[e]->(c)",
__.as('p').hasLabel('Person').out('employed_at').has('Company', 'name',
'Foo'),
__.as('e').hasLabel('employed_at'),
__.as('c').hasLabel('Company'),
)

Thoughts?

Dave

Re: [DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

of data and logic.
> >
>
> cool - hope you like the revised syntax I posted then. :)
>
>
> > That's my humble take. This is a very welcome addition to the language
> and
> > I appreciate the thoughtful & collaborative approach to the design
> > considerations.
> >
>
> Thanks again and please keep the thoughts coming. Lots of other interesting
> design discussions seem to be brewing.
>
>
> >
> > Josh
> >
> > On Tue, Dec 8, 2020 at 8:57 AM Stephen Mallette 
> > wrote:
> >
> > > I started a expanded this discussion to gremlin-users for a wider
> > audience
> > > and the thread is starting to grow:
> > >
> > > https://groups.google.com/g/gremlin-users/c/QBmiOUkA0iI/m/pj5Ukiq6AAAJ
> > >
> > > I guess we'll need to summarize that discussion back here now
> > >
> > > I did have some more thoughts to hang out there and figured that I
> > wouldn't
> > > convolute the discussion on gremlin-users with it so I will continue
> the
> > > discussion here.
> > >
> > > 1, The very first couple of examples seem wrong (or at least not best
> > > demonstrating the usage):
> > >
> > > g.upsertV('person', [name: 'marko'],
> > > [name: 'marko', age: 29])
> > > g.upsertV('person', [(T.id): 1],
> > > [(T.id): 1, name: 'Marko'])
> > >
> > > should instead be:
> > >
> > > g.upsertV('person', [name: 'marko'],
> > > [age: 29])
> > > g.upsertV('person', [(T.id): 1],
> > > [name: 'Marko'])
> > >
> > > 2. I can't recall if we made this clear anywhere but in situations
> where
> > we
> > > "get" rather than "create" do the additional properties act in an
> update
> > > fashion to the element that was found? I think I've been working on the
> > > assumption that it would, though perhaps that is not always desirable?
> > >
> > > 3. We really never settled up how to deal with multi/meta-properties.
> > That
> > > story should be clear so that when we document upsert() we include the
> > > approaches for the fallback patterns that don't meet the 90% of use
> cases
> > > we are targeting and I sense that we're saying that
> meta/multi-properties
> > > don't fit in that bucket. So with that in mind, I don't think that the
> > > following works for metaproperties:
> > >
> > > g.upsertV('person', [(T.id): 1],
> > > [name:[acl: 'public'])
> > >
> > > as it doesn't let us set the value for the "name" just the pairs for
> the
> > > meta-properties. I guess a user would have to fall back to:
> > >
> > > g.upsertV('person', [(T.id): 1]).
> > >   property('name','marko','acl','public')
> > >
> > > // or use the additional properties syntax
> > > g.upsertV('person', [(T.id): 1],[name:'marko']).
> > >   properties('name').property('acl','public')
> > >
> > > // or if there were multi-properties then maybe...
> > > g.upsertV('person', [(T.id): 1],[name:'marko']).
> > >   properties('name').hasValue('marko').property('acl','public')
> > >
> > > As for multi-properties, I dont think we should assume that a List
> object
> > > should be interpreted by Gremlin as a multi-property. Perhaps we just
> > rely
> > > on the underlying graph to properly deal with that given a schema or
> the
> > > user falls back to:
> > >
> > > // this ends up as however the graph deals with a List object
> > > g.upsertV('person', [(T.id): 1], [lang: ['java', 'scala', 'java'])
> > >
> > > // this is explicit
> > > g.upsertV('person', [(T.id): 1]).
> > >   property(list, 'lang', 'java').
> > >   property(list, 'lang, 'scala').
> > >   property(list, 'lang', 'java')
> > >
> > > If that makes sense to everyone, I will update the gist.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Oct 27, 2020 at 11:51 PM David Bechberger  >
> > > wrote:
> > >
> > > > Hello Stephen,
> > > >
> > > > Thanks for making that gist, its much easier to follow along with the
> > > > proposed syntax there.  To your specific comments:
> > > >
> > > > #1 - My only worry with the term upsert is that it is not as widely a
> > > used
> > 

Re: [DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

For #1 and 3 I agree.  For #2 I thought that we agreed that the properties
within the upsert were going to be for creation only and that any
properties that needed to be updated would be done via the standard
property() syntax after the upsert.  e.g.

g.upsertV('person', [name: 'marko'],
[age: 29]).property('lang', 'java')

If it does not exist then this would create a vertex with the 'name',
'age', and 'lang' properties.  If it does exist then it would just update
the 'lang' property.

Dave

On Tue, Dec 8, 2020 at 5:57 AM Stephen Mallette 
wrote:

> I started a expanded this discussion to gremlin-users for a wider audience
> and the thread is starting to grow:
>
> https://groups.google.com/g/gremlin-users/c/QBmiOUkA0iI/m/pj5Ukiq6AAAJ
>
> I guess we'll need to summarize that discussion back here now
>
> I did have some more thoughts to hang out there and figured that I wouldn't
> convolute the discussion on gremlin-users with it so I will continue the
> discussion here.
>
> 1, The very first couple of examples seem wrong (or at least not best
> demonstrating the usage):
>
> g.upsertV('person', [name: 'marko'],
> [name: 'marko', age: 29])
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, name: 'Marko'])
>
> should instead be:
>
> g.upsertV('person', [name: 'marko'],
> [age: 29])
> g.upsertV('person', [(T.id): 1],
> [name: 'Marko'])
>
> 2. I can't recall if we made this clear anywhere but in situations where we
> "get" rather than "create" do the additional properties act in an update
> fashion to the element that was found? I think I've been working on the
> assumption that it would, though perhaps that is not always desirable?
>
> 3. We really never settled up how to deal with multi/meta-properties. That
> story should be clear so that when we document upsert() we include the
> approaches for the fallback patterns that don't meet the 90% of use cases
> we are targeting and I sense that we're saying that meta/multi-properties
> don't fit in that bucket. So with that in mind, I don't think that the
> following works for metaproperties:
>
> g.upsertV('person', [(T.id): 1],
> [name:[acl: 'public'])
>
> as it doesn't let us set the value for the "name" just the pairs for the
> meta-properties. I guess a user would have to fall back to:
>
> g.upsertV('person', [(T.id): 1]).
>   property('name','marko','acl','public')
>
> // or use the additional properties syntax
> g.upsertV('person', [(T.id): 1],[name:'marko']).
>   properties('name').property('acl','public')
>
> // or if there were multi-properties then maybe...
> g.upsertV('person', [(T.id): 1],[name:'marko']).
>   properties('name').hasValue('marko').property('acl','public')
>
> As for multi-properties, I dont think we should assume that a List object
> should be interpreted by Gremlin as a multi-property. Perhaps we just rely
> on the underlying graph to properly deal with that given a schema or the
> user falls back to:
>
> // this ends up as however the graph deals with a List object
> g.upsertV('person', [(T.id): 1], [lang: ['java', 'scala', 'java'])
>
> // this is explicit
> g.upsertV('person', [(T.id): 1]).
>   property(list, 'lang', 'java').
>   property(list, 'lang, 'scala').
>   property(list, 'lang', 'java')
>
> If that makes sense to everyone, I will update the gist.
>
>
>
>
>
>
>
> On Tue, Oct 27, 2020 at 11:51 PM David Bechberger 
> wrote:
>
> > Hello Stephen,
> >
> > Thanks for making that gist, its much easier to follow along with the
> > proposed syntax there.  To your specific comments:
> >
> > #1 - My only worry with the term upsert is that it is not as widely a
> used
> > term for this sort of pattern as "Merge" (e.g. SQL, Cypher).  However I
> > don't have a strong opinion on this, so I am fine with either.
> > #2 - My only real objective here is to make sure that we make the 80-90%
> > case easy and straightforward.  I think that having the fallback option
> of
> > using the current syntax for any complicated edge cases should be
> > considered here as well. I'd appreciate your thoughts here as these are
> > good points you bring up that definitely fall into the 80-90% use case.
> > #3 - Those points make sense to me, not sure I have anything further to
> add
> > #4 - I don't think I would expect to have the values extracted from the
> > traversal filters but I'd be interested in other opinions on that.
> >
> > Thanks,
> > Dave
> >
> > On Thu, Oct 15, 2020 at 5:30 AM Stephen Mallette 
> > wr

[DISCUSS] Add functions for casting properties

[David Bechberger]

One of the recent items I have heard quite a few requests for, and had
several on and off conversations about, is the ability to cast values
within a Gremlin traversal.  Due to the schemaless nature of Gremlin it is
very easy to get into a situation where you have a single property that
contains different datatypes across elements and it would be very nice to
be able to create a consistent datatype to allow comparisons.  I'd like to
throw this proposal out here to see what people think.

What if we added a step to handle converting to a defined subset of
datatypes:


Function Signature:

cast(Enum, string)

Enum - This would be an enum containing the datatypes you can cast to:
* DT.short
* DT.int
* DT.long
* DT.float
* DT.double
* DT.char
* DT.boolean
* DT.string

string - The property name to cast

Example usages:

g.V().project('name', 'age').by(cast(DT.String, 'name')).by(cast(DT.int,
'age'))
g.V().order().by(cast(DT.int, 'age'))
g.V().group().by(cast(DT.int, 'age'))

So what happens if the value cannot be cast to the defined type:

I think that the default behavior in this case should be to throw an error.

I would like to provide two configuration options (via with)

with(CAST.remove) - in any case where the value cannot be cast the
traverser would be filtered out

with(CAST.default, -999) - in any case the value cannot be cast the
specified default value (e.g. -999) would be used.  This would reduce the
complexity and increase the readability of many queries by no longer
requiring the use of a coalesce() to handle creation of default values .
This would also enable customers to handle use cases where data is of
varying types which cannot be handled by the current coalesce() pattern.

Dave

Re: [DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

> filtering patterns that users follow really well. I suppose the question is
> what to do in the situation of "create". Would we extract all the strict
> equality filter values from the initial has(), thus, in the example,
> "state" but not "age", and create a vertex that has "state=NY,
> active=true"? That is possible with how things are designed in Gremlin
> today I think.
>
> This syntax does create some conflict with the subject of 3 and streams
> because the traverser in the streams case is the incoming Map but for this
> context it's meant as a filter of V(). Getting too whacky?
>
> 5. I like the idea of using a side-effect to capture whether the element
> was created or not. that makes sense. I think that can work.
>
> ==
> = gist contents
> ==
>
> # API
>
> ```java
> upsertV(String label, Map matchOrCreateProperties)
> upsertV(String label, Map matchOrCreateProperties, Map
> additionalProperties)
> upsertV(Traversal label, Traversal matchOrCreateProperties)
> upsertV(Traversal label, Traversal matchOrCreateProperties, Traversal
> additionalProperties)
> upsertV(...).
>   with(WithOptions.sideEffectLabel, 'a')
>
> upsertE(String label, Map matchOrCreateProperties)
> upsertE(Traversal label, Traversal matchOrCreateProperties)
> upsertE(String label, Map matchOrCreateProperties, Map
> additionalProperties)
> upsertE(Traversal label, Traversal matchOrCreateProperties, Traversal
> additionalProperties)
> upsertE(...).
>   from(Vertex incidentOut).to(Vertex incidentIn)
>   with(WithOptions.sideEffectLabel, 'a')
> ```
>
> # Examples
>
> ## upsert
>
> ```groovy
> g.upsertV('person', [name: 'marko'],
> [name: 'marko', age: 29])
> ```
>
> ## upsert with id
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, name: 'Marko'])
> ```
>
> ## upsert with Meta Properties
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, name:[first: Marko', last: 'R'])
> ```
>
> ## upsert with Multi Properties
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1,lang: ['java', 'scala'])
> ```
>
> ## upsert with Single Cardinality
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, lang: 'java')
> ```
>
> ## upsert with List Cardinality
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, lang: ['java', 'scala', 'java'])
> ```
>
> ## upsert with Set Cardinality
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, lang: ['java','scala'])
> ```
>
> ## upsert with List Cardinality - and add value to list
>
> ```groovy
> g.upsertV('person', [(T.id): 1],
> [(T.id): 1, lang: ['java','scala','java']).
>   property(Cardinality.list, 'lang', 'java')
> ```
>
> ## upsert with stream
>
> ```groovy
> // doesn't work with today's Gremlin semantics
> g.inject([(id): 1, (label): 'person', name: 'marko'],
>  [(id): 2, (label): 'person', name: 'josh']).
>   upsertV(values(label), valueMap(id), valueMap())
>
> // the following would be more in line with what's possible with existing
> Gremlin semantics:
> g.inject([id: 1, label: 'person', name: 'marko'],
>  [id: 2, label: 'person', name: 'josh']).
>   upsertV(select('label'), select('id'), select('id','label','name'))
> ```
>
> ## upsert with reporting added or updated side effect
>
> ```groovy
> g.upsertV('person', [name: 'marko'],
>     [name: 'marko', age: 29]).
> with(WithOptions.sideEffectLabel, 'a').
>   project('vertex', 'added').
> by().
> by(cap('a'))
> ```
>
> ## upsert Edge assuming a self-relation of "marko"
>
> ```groovy
> g.V().has('person','name','marko').
>   upsertE( 'self', [weight:0.5])
> ```
>
> ## upsert Edge with incident vertex checks
>
> ```groovy
> g.upsertE('knows', [weight:0.5]).
>from(V(1)).to(V(2))
> g.V().has('person','name','marko').
>   upsertE( 'knows', [weight:0.5]).
> to(V(2))
> ```
>
> ## upsert using a Traversal for the match
>
> ```groovy
> g.V().upsertV('person', __.has('person','age',gt(29)).has('state', 'NY'),
> [active: true])
> ```
>
>
>
>
> On Mon, Sep 28, 2020 at 6:49 PM David Bechberger 
> wrote:
>
> > So, I've been doing some additional thinking about the ways that this
> could
> > work based on the comments below and have put my comments inline.
> >
> > Dave
> >

Re: [DISCUSS] Adding examples for client usage

[David Bechberger]

I am favoring Divij's proposal and replacing the current examples (which I
didn't even know about until now) with a repo of examples similar to
netty.

On Fri, Oct 9, 2020 at 3:49 AM Stephen Mallette 
wrote:

> I like the idea for /examples especially when using netty as the context. I
> think it's smart to put these in a specific "TinkerPop Driver Guide" too.
>
> I wonder if /examples removes the need for the project templates we
> maintain now. In other words, if we have fully working examples in all
> languages do we need to have gremlin-archetype, Gremlin.Net.Template and
> the random example.py? I think our motivation in adding those was more to
> provide example usage in platform specific ways, but to use project
> template infrastructure for that seems over done. It's not like we generate
> all this project infrastructure like Spring or Hibernate. We basically just
> generate little main() functions and some example code. I think we might be
> able to drop all that. Thoughts?
>
>
>
> On Thu, Oct 8, 2020 at 6:50 PM Divij Vaidya 
> wrote:
>
> > Hello all
> >
> > This is regarding https://issues.apache.org/jira/browse/TINKERPOP-2244
> > 
> >
> > I wanted to discuss the right place to put the example code at. My
> > suggestion is as follows and please let me know if you have any
> > suggestions.
> >
> > 1. Create a new examples plugin in the main TinkerPop maven project
> similar
> > to netty project .
> > 2. Examples for all languages will be added there.
> > 3. The examples will be cross linked from the main website similar to
> this
> > Google SDK  i.e.
> > tabs for multiple languages with a link to github code on each.
> > 4. These examples will be available in https://tinkerpop.apache.org/ >
> > Tutorials > TinkerPop driver user guide.
> >
> > Divij Vaidya
> >
>

Re: [DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

So, I've been doing some additional thinking about the ways that this could
work based on the comments below and have put my comments inline.

Dave

On Tue, Sep 22, 2020 at 6:05 AM Stephen Mallette 
wrote:

> I added some thoughts inline below:
>
> On Fri, Sep 18, 2020 at 3:51 PM David Bechberger 
> wrote:
>
> > Thanks for the detailed comments Stephen.  I have addressed them inline
> > below.
> >
> > I did read the proposal from earlier and I think that we are in close
> > agreement with what we are trying to accomplish.  I also fully support
> > Josh's comment on providing a mechanism for submitting a map of
> properties
> > as manually unrolling this all right now leads to a lot of potential for
> > error and a long messy traversal.
> >
> > I'm looking forward to this discussion on how to merge these two
> proposals.
> >
> >
> > 1. How would multi/meta-properties fit into the API you've proposed?
> >
> > My first thought here is that multi-properties would be represented as
> > lists in the map, e.g.
> >
> > {names: ['Dave', 'David']}
> >
> > and meta-properties would be represented as maps in the maps, e.g.
> >
> > {name: {first: 'Dave', last: 'Bechberger'}}
> >
> > I can't say I've thought through all the implications of this though so
> it
> > is an area we would need to explore.
> >
>
> The first implication that comes to mind is that it makes the assumption
> the user wants multi/meta-properties as opposed to a single cardinality of
> List in the first case and a Map as a property value in the second case. I
> suppose that graphs with a schema could resolve those assumptions but
> graphs that are schemaless would have a problem. The issue could be
> resolved by specialized configuration of "g" or per merge() step using a
> with() modulator I suppose but that goes into a yet another level of
> implications to consider. I've often wondered if the start point for
> getting types/schema into TP3 without a full rewrite would be in this form
> where Gremlin would be given hints as to what to expect as to the types of
> data it might encounter while traversing. Anyway, I'd be hesitant to go
> down paths that don't account for multi/metaproperties well.  They are
> first class citizens in TP3 (with those hoping for extension of at least
> multiproperties to edges) and while I find them a constant annoyance for so
> many reasons, we're kinda stuck with them.
>

I agree we need to account for multi/meta properties as 1st class
citizens.  This is my current thinking on the syntax for the situations we
have laid out so far:

*Merge*
g.mergeV('name', {'name': 'marko'}, {'name': 'marko', 'age': 29})


*Merge with id* g.mergeV('name', {T.id: 1}, {T.id: 1, 'name': 'Marko'})


*Merge with Meta Properties* g.mergeV('name', {T.id: 1}, {T.id: 1, 'name':
{'first': Marko', 'last': 'R'})


*Merge with Multi Properties * g.mergeV('name', {T.id: 1}, {T.id: 1,
'lang': ['java', 'scala'])


*Merge with Single Cardinality* g.mergeV('name', {T.id: 1}, {T.id: 1,
'lang': 'java')


*Merge with List Cardinality* g.mergeV('name', {T.id: 1}, {T.id: 1, 'lang':
['java', 'scala', 'java'])


*Merge with Set Cardinality * g.mergeV('name', {T.id: 1}, {T.id: 1, 'lang':
['java', 'scala'])

Since in a mergeV() scenario we are only ever adding whatever values are
passed in there would be no need to specify the cardinality of the property
being added.  If they wanted to add a value to an existing property then
the current property() method would still be available on the output
traversal. e.g.
g.mergeV('name', {T.id: 1}, {T.id: 1, 'lang': ['java', 'scala',
'java']).property(Cardinality.list, 'lang, 'java')


*Merge with stream * g.inject([{id: 1, label: 'person', 'name': 'marko'},
{id: 2, label: 'person', 'name': 'josh'}]).
  mergeV(values('label'), valueMap('id'), valueMap())


*Merge with reporting added or updated side effect* g.mergeV('name',
{'name': 'marko'}, {'name': 'marko', 'age': 29}).
  with(WithOptions.sideEffectLabel, 'a').
  project('vertex', 'added').
by().
by(cap('a'))



>
>
> > 2. How would users set the T.id on creation? would that T.id just be a
> key
> > in the first Map argument?
> >
> > Yes, I was thinking that T.id would be the key name, e.g.:
> >
> > g.mergeV('name', {T.id: 1}, {'name': 'Marko'})
> >
>
> ok - I can't say I see a problem with that atm.
>
>
> > 3. I do like the general idea of a match on multiple properties for the
> > first argument as a convenience but wonder about the specificity of this
> > API a bit as it focuses heavily on equality - I suppose that's most cases
> > for get-or-create, so perhaps that's ok.
> >
> > In most cases I've seen use ex

Re: [DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

 introducing your ideas here, so perhaps you haven't gotten
this far yet, but a shortcoming to doing merge(String,Map,Map) is that it
leaves open no opportunity to stream a List of Maps to a merge() for a form
of batch loading which is mighty common and one of the variations of the
coalesce() pattern that I alluded to at the start of all this. I think that
we would want to be sure that we left open the option to do that somehow.
8. If we had a general purpose merge() step I wonder if it makes developing
the API as you suggested easier to do?

Hmm, let me think about that one.

On Thu, Sep 17, 2020 at 4:31 AM Stephen Mallette 
wrote:

> I like our coalesce() pattern but it is verbose and over time it has gone
> from a simple pattern to one with numerous variations for all manner of
> different sorts of merge-like operations. As such, I do think we should
> introduce something to cover this pattern.
>
> I like that you used the word "merge" in your description of this as it is
> the word I've liked using. You might want to give a look at my proposed
> merge() step from earlier in the year:
>
>
> https://lists.apache.org/thread.html/r34ff112e18f4e763390303501fc07c82559d71667444339bde61053f%40%3Cdev.tinkerpop.apache.org%3E
>
> I'm just going to dump thoughts as they come regarding what you wrote:
>
> 1. How would multi/meta-properties fit into the API you've proposed?
> 2. How would users set the T.id on creation? would that T.id just be a key
> in the first Map argument?
> 3. I do like the general idea of a match on multiple properties for the
> first argument as a convenience but wonder about the specificity of this
> API a bit as it focuses heavily on equality - I suppose that's most cases
> for get-or-create, so perhaps that's ok.
> 4. I think your suggestion points to one of the troubles Gremlin has which
> we see with "algorithms" - extending the language with new steps that
> provides a form of "sugar" (e.g. in algorithms we end up with
> shortestPath() step) pollutes the core language a bit, hence my
> generalization of "merging" in my link above which fits into the core
> Gremlin language style. There is a bigger picture where we are missing
> something in Gremlin that lets us extend the language in ways that let us
> easily introduce new steps that aren't for general purpose. This issue is
> discussed in terms of "algorithms" here:
> https://issues.apache.org/jira/browse/TINKERPOP-1991 but I think we could
> see how there might be some "mutation" extension steps that would cover
> your suggested API, plus batch operations, etc. We need a way to add
> "sugar" without it interfering with the consistency of the core. Obviously
> this is a bigger issue but perhaps important to solve to implement steps in
> the fashion you describe.
> 5. I suppose that the reason for mergeE and mergeV is to specify what
> element type the first Map argument should be applied to? what about
> mergeVP (i.e. vertex property as it too is an element) ? That's tricky but
> I don't think we should miss that. Perhaps merge() could be a "complex
> modulator"?? that's a new concept of course, but you would do g.V().merge()
> and the label and first Map would fold to VertexStartStep (i.e. V()) for
> the lookup and then a MergeStep would follow - thus a "complex modulator"
> as it does more than just change the behavior of the previous step - it
> also adds its own. I suppose it could also add has() steps followed by the
> MergeStep and then the has() operations would fold in normally as they do
> today. In this way, we can simplify to just one single
> merge(String,Map,Map). ??
> 6. One thing neither my approach nor yours seems to do is tell the user if
> they created something or updated something - that's another thing I've
> seen users want to have in get-or-create. Here again we go deeper into a
> less general step specification as alluded to in 4, but a merge() step as
> proposed in 5, might return [Element,boolean] so as to provide an indicator
> of creation?
> 7. You were just introducing your ideas here, so perhaps you haven't gotten
> this far yet, but a shortcoming to doing merge(String,Map,Map) is that it
> leaves open no opportunity to stream a List of Maps to a merge() for a form
> of batch loading which is mighty common and one of the variations of the
> coalesce() pattern that I alluded to at the start of all this. I think that
> we would want to be sure that we left open the option to do that somehow.
> 8. If we had a general purpose merge() step I wonder if it makes developing
> the API as you suggested easier to do?
>
> I think I'd like to solve the problems you describe in your post as well as
> the ones in mine. There is some relation th

[DISCUSS] Creating pattern steps to codify best practices

[David Bechberger]

I've had a few on and off discussions with a few people here, so I wanted
to send this out to everyone for feedback.

What are people's thoughts on creating a new set of steps that codify
common Gremlin best practices?

I think there are several common Gremlin patterns where users would benefit
from the additional guidance that these codified steps represent.  The
first one I would recommend though is codifying the element existence
pattern into a single Gremlin step, something like:

mergeV(String, Map, Map)
 String - The vertex label
 Map (first) - The properties to match existing vertices on
 Map (second) - Any additional properties to set if a new vertex is
created (optional)
mergeE(String, Map, Map)
 String - The edge label
 Map (first) - The properties to match existing edge on
 Map (second) - Any additional properties to set if a new edge is
created (optional)

In each of these cases these steps would perform the same upsert
functionality as the element existence pattern.

Example:

g.V().has('person','name','stephen').
   fold().
   coalesce(unfold(),
addV('person').
  property('name','stephen').
  property('age',34))

would become:

g.mergeV('person', {'name': 'stephen'}, {'age', 34})

I think that this change would be a good addition to the language for
several reasons:

* This codifies the best practice for a specific action/recipe, which
reduces the chance that someone uses the pattern incorrectly
* Most complex Gremlin traversals are verbose.  Reducing the amount of code
that needs to be written and maintained allows for a better developer
experience.
* It will lower the bar of entry for a developer by making these actions
more discoverable.  The more we can help bring these patterns to the
forefront of the language via these pattern/meta steps the more we guide
users towards writing better Gremlin faster
* This allows DB vendors to optimize for this pattern

I know that this would likely be the first step in Gremlin that codifies a
pattern, so I'd like to get other's thoughts on this?

Dave

Re: [DISCUSS] Accepting gremlint donation

[David Bechberger]

I definitely agree that having this sort of tool freely available would be
very helpful to the community as a whole.

I also would be able to help create the translator between GLV's and text
representations as this is something I and many others have struggled with
many times.

Thanks,
Dave

On Thu, Sep 10, 2020 at 2:14 PM Kelvin Lawrence 
wrote:

> I really like the idea of having an Apache TinkerPop hosted linter and
> style guide "enforcer". I have spent many wasted hours hand formatting long
> Gremlin queries people have asked me to look at over the years and the
> latest version of Gremlint makes that so much easier. I also really like
> the idea of extending the tool in the direction of "Gremlin converter". I
> hear from a lot of users that porting from (let's say) Gremlin Console to
> Gremlin Python (and vice-versa) is painful and hard to get right.
>
> Cheers
> Kelvin
>
> On 2020/09/10 11:07:46, Stephen Mallette  wrote:
> > I've had some on and off discussions with the developer of>
> >
> > https://gremlint.com/>
> >
> > whose name is Øyvind btw, about the possibility of making gremlint the>
> > canonical Gremlin code stylizer, and by that I mean, his donating the
> code>
> > (and domain name) to the Apache Software Foundation under our project.
> That>
> > situation seems possible now and has been offered to the TinkerPop>
> > Community.>
> >
> > I like the idea of bringing this code here because I feel our style
> guide>
> > in Gremlin Recipes can only suggest convention and I'd much like to see
> a>
> > code library managed by our project enforce a proper Gremlin style that
> can>
> > be used not only as the neat single HTML page of gremlint.com but also
> as a>
> > code library to Gremlin tool builders.>
> >
> > I also see the opportunity to grow this tool into an online translator
> to>
> > get you from one Gremlin dialect to another which is a constant problem
> for>
> > users who are working with the tons of code examples in Gremlin Groovy
> but>
> > need to get a fast conversion to Python or Javascript. I know I've had
> that>
> > problem myself on many occasions. An easy to use translator like this
> would>
> > help users realize that Gremlin in Groovy isn't so different from
> Gremlin>
> > in any other language and that once you know the subtleties of the>
> > differences you can easily learn Gremlin from any example in any
> language.>
> >
> > I've not given a ton of thought to how gremlint would be brought in,
> where>
> > it would go in our source code tree, or how it fits in to>
> > release/deployment, but all that discussion can come later. I think
> that>
> > for right now, we should simply find consensus on whether or not to go
> down>
> > this path.>
> >
> > Are there any thoughts or concerns about accepting this code base and
> the>
> > gremlint.com domain?>
> >
> Cheers,
> Kelvin
>
>
>