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 <d...@bechberger.com> 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 <d...@bechberger.com> 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 <d...@bechberger.com> > 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 >> <valent...@bitquilltech.com.invalid> 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 <d...@bechberger.com> >>> 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 <d...@bechberger.com> >>> > 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 >>> > > >>> > >>> >>
