Re: [DISCUSS] P.not and __.not
VOTE: +1 for the deprecation of P.not. 1. nobody's using it 2. you can have the same result using otherPredicate.negate() 3. when people write not(...) they usually want the NotStep On Fri, Feb 24, 2017 at 8:34 PM, Stephen Mallette wrote: > P.not and __.not unfortunately tangle with each other when using static > imports. I think we allowed the console to dictate to us that P.not is the > lucky one that gets to be used without its qualifying prefix. I'm not sure > there was any conscious decision to do it that way. Indeed, I think i would > prefer getting __.not over P.not. I also think that the behavior is sort of > random that we get P.not rather than __.not (for reasons I can go into in > more detail if anyone cares). > > Anyway, I'd like to resolve this issue in 3.3.0. I think that immediately, > I can introduce the breaking change to the console that explicitly imports > __.not rather than P.not - this will remove randomness. In the longer term > we can deprecate P.not and either drop it all together or rename it. I'm > not sure how strongly folks feel about usage of P.not so I guess I'll just > open it up for discussion as to what the long term fix should be here. > > If we don't develop any real consensus here for the longer term option I > will just create an issue in JIRA and it can be dealt with later. I'm > mostly interested in getting a short-term solution in place to solve some > problems I'm facing right now. > > Thanks, > > Stephen >
RE: [DISCUSS] P.not and __.not
If you'll forgive "thinking out loud," is there any way to create a wrapper-not that implements both interfaces and just works? -Original Message- From: Stephen Mallette [mailto:spmalle...@gmail.com] Sent: Friday, February 24, 2017 2:35 PM To: dev@tinkerpop.apache.org Subject: [DISCUSS] P.not and __.not P.not and __.not unfortunately tangle with each other when using static imports. I think we allowed the console to dictate to us that P.not is the lucky one that gets to be used without its qualifying prefix. I'm not sure there was any conscious decision to do it that way. Indeed, I think i would prefer getting __.not over P.not. I also think that the behavior is sort of random that we get P.not rather than __.not (for reasons I can go into in more detail if anyone cares). Anyway, I'd like to resolve this issue in 3.3.0. I think that immediately, I can introduce the breaking change to the console that explicitly imports __.not rather than P.not - this will remove randomness. In the longer term we can deprecate P.not and either drop it all together or rename it. I'm not sure how strongly folks feel about usage of P.not so I guess I'll just open it up for discussion as to what the long term fix should be here. If we don't develop any real consensus here for the longer term option I will just create an issue in JIRA and it can be dealt with later. I'm mostly interested in getting a short-term solution in place to solve some problems I'm facing right now. Thanks, Stephen
Re: [DISCUSS] P.not and __.not
marko, i didn't realize that choice was intentional. ok - guess i'll keep hating my life then On Fri, Feb 24, 2017 at 2:42 PM, Marko Rodriguez wrote: > Hi, > > It is not random. Preference is always given to the P operators over their > traversal counterparts. If there is some random component, we should fix > it, but we should always give precedence to P so we are backwards > compatible. > > Marko. > > http://markorodriguez.com > > > > > On Feb 24, 2017, at 12:34 PM, Stephen Mallette > wrote: > > > > P.not and __.not unfortunately tangle with each other when using static > > imports. I think we allowed the console to dictate to us that P.not is > the > > lucky one that gets to be used without its qualifying prefix. I'm not > sure > > there was any conscious decision to do it that way. Indeed, I think i > would > > prefer getting __.not over P.not. I also think that the behavior is sort > of > > random that we get P.not rather than __.not (for reasons I can go into in > > more detail if anyone cares). > > > > Anyway, I'd like to resolve this issue in 3.3.0. I think that > immediately, > > I can introduce the breaking change to the console that explicitly > imports > > __.not rather than P.not - this will remove randomness. In the longer > term > > we can deprecate P.not and either drop it all together or rename it. I'm > > not sure how strongly folks feel about usage of P.not so I guess I'll > just > > open it up for discussion as to what the long term fix should be here. > > > > If we don't develop any real consensus here for the longer term option I > > will just create an issue in JIRA and it can be dealt with later. I'm > > mostly interested in getting a short-term solution in place to solve some > > problems I'm facing right now. > > > > Thanks, > > > > Stephen > >
Re: [DISCUSS] P.not and __.not
Hi, It is not random. Preference is always given to the P operators over their traversal counterparts. If there is some random component, we should fix it, but we should always give precedence to P so we are backwards compatible. Marko. http://markorodriguez.com > On Feb 24, 2017, at 12:34 PM, Stephen Mallette wrote: > > P.not and __.not unfortunately tangle with each other when using static > imports. I think we allowed the console to dictate to us that P.not is the > lucky one that gets to be used without its qualifying prefix. I'm not sure > there was any conscious decision to do it that way. Indeed, I think i would > prefer getting __.not over P.not. I also think that the behavior is sort of > random that we get P.not rather than __.not (for reasons I can go into in > more detail if anyone cares). > > Anyway, I'd like to resolve this issue in 3.3.0. I think that immediately, > I can introduce the breaking change to the console that explicitly imports > __.not rather than P.not - this will remove randomness. In the longer term > we can deprecate P.not and either drop it all together or rename it. I'm > not sure how strongly folks feel about usage of P.not so I guess I'll just > open it up for discussion as to what the long term fix should be here. > > If we don't develop any real consensus here for the longer term option I > will just create an issue in JIRA and it can be dealt with later. I'm > mostly interested in getting a short-term solution in place to solve some > problems I'm facing right now. > > Thanks, > > Stephen
[DISCUSS] P.not and __.not
P.not and __.not unfortunately tangle with each other when using static imports. I think we allowed the console to dictate to us that P.not is the lucky one that gets to be used without its qualifying prefix. I'm not sure there was any conscious decision to do it that way. Indeed, I think i would prefer getting __.not over P.not. I also think that the behavior is sort of random that we get P.not rather than __.not (for reasons I can go into in more detail if anyone cares). Anyway, I'd like to resolve this issue in 3.3.0. I think that immediately, I can introduce the breaking change to the console that explicitly imports __.not rather than P.not - this will remove randomness. In the longer term we can deprecate P.not and either drop it all together or rename it. I'm not sure how strongly folks feel about usage of P.not so I guess I'll just open it up for discussion as to what the long term fix should be here. If we don't develop any real consensus here for the longer term option I will just create an issue in JIRA and it can be dealt with later. I'm mostly interested in getting a short-term solution in place to solve some problems I'm facing right now. Thanks, Stephen
[jira] [Closed] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-1639.
-
Resolution: Won't Fix
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882966#comment-15882966
]
pieter martin commented on TINKERPOP-1639:
--
Another operation to think about is casting.
It is often the case that when the data is loaded the proper type is not known
and the property is captured as a `String`. Later an analyst or whoever
actually understands the data can cast it to the proper type and do further
manipulations on it.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882992#comment-15882992
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
Github user dkuppitz closed the pull request at:
https://github.com/apache/tinkerpop/pull/564
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882991#comment-15882991
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/564
It's true that this was just "would be cool" PR, that would have helped me
in the short term. The general solution to this problem is proposed in
https://issues.apache.org/jira/browse/TINKERPOP-1632.
Closing.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #564: TINKERPOP-1639 Support simple String operations
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/564 It's true that this was just "would be cool" PR, that would have helped me in the short term. The general solution to this problem is proposed in https://issues.apache.org/jira/browse/TINKERPOP-1632. Closing. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop pull request #564: TINKERPOP-1639 Support simple String operations
Github user dkuppitz closed the pull request at: https://github.com/apache/tinkerpop/pull/564 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz updated TINKERPOP-1639:
--
Fix Version/s: (was: 3.2.5)
(was: 3.3.0)
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882931#comment-15882931
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/564
Also, what other string operations do we need? I'm thinking reg-ex.
So now we have a `filter()` steps for regex, but then what about pattern
matching selection. Well, thats not range, but something new. Now you have all
your string manipulation features spread out across numerous steps. Is this
good? I don't know. Seems that all primitive operations should be grouped via
predicate and operators else we will just be building a new data flow language
(steps steps steps steps) for primitives and all the operations you want to do
on them.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #564: TINKERPOP-1639 Support simple String operations
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/564 Also, what other string operations do we need? I'm thinking reg-ex. So now we have a `filter()` steps for regex, but then what about pattern matching selection. Well, thats not range, but something new. Now you have all your string manipulation features spread out across numerous steps. Is this good? I don't know. Seems that all primitive operations should be grouped via predicate and operators else we will just be building a new data flow language (steps steps steps steps) for primitives and all the operations you want to do on them. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] tinkerpop issue #564: TINKERPOP-1639 Support simple String operations
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/564 @dkuppitz asked me to say more of my thoughts on the matter. I think we need a general theory for how we are going to handle primitive manipulations. That is, math operators, string operations, character operations, type casting operations, etc. If we just append this feature for `Strings` then we might end up backtracking come a more general theory. It just seems that this PR is a "this would be cool" and implemented. Not: "So, primitives all fit this style of manipulation in a flow-based system..." Questions that arise: * What about `unfold()`? Now we are in character manipulation or just single character strings? * What about `fold()`? Does character folding become strings? * What about `range()` on doubles/floats? Is that a way to clip precision? I don't think we should just add this PR without a fully thought through model for all primitives and how they will be effected by the current or "need to be built" steps. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882907#comment-15882907
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/564
@dkuppitz asked me to say more of my thoughts on the matter.
I think we need a general theory for how we are going to handle primitive
manipulations. That is, math operators, string operations, character
operations, type casting operations, etc.
If we just append this feature for `Strings` then we might end up
backtracking come a more general theory. It just seems that this PR is a "this
would be cool" and implemented. Not: "So, primitives all fit this style of
manipulation in a flow-based system..."
Questions that arise:
* What about `unfold()`? Now we are in character manipulation or just
single character strings?
* What about `fold()`? Does character folding become strings?
* What about `range()` on doubles/floats? Is that a way to clip precision?
I don't think we should just add this PR without a fully thought through
model for all primitives and how they will be effected by the current or "need
to be built" steps.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882795#comment-15882795
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/564
I do not think we should support this feature. This is starting to mix
semantics between what is a "data structure" and what is a "primitive."
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop issue #564: TINKERPOP-1639 Support simple String operations
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/564 I do not think we should support this feature. This is starting to mix semantics between what is a "data structure" and what is a "primitive." --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (TINKERPOP-1640) ComputerVerificationStrategy gives false errors
Daniel Kuppitz created TINKERPOP-1640:
-
Summary: ComputerVerificationStrategy gives false errors
Key: TINKERPOP-1640
URL: https://issues.apache.org/jira/browse/TINKERPOP-1640
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.2.4
Reporter: Daniel Kuppitz
Assignee: Marko A. Rodriguez
I've added a new complex test that fails in OLAP. Unfortunately the test runner
only marks the test as "ignored" as that's what we usually we want when a
{{VerificationException}} is thrown. However, in this case the exception ("It
is not possible to access more than a path element's id on GraphComputer: ...")
is wrong.
Another issue that I just noticed is, that the same test throw serialization
exceptions in the {{\*Translator\*}} test suites.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1639) Support simple String operations
[
https://issues.apache.org/jira/browse/TINKERPOP-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882395#comment-15882395
]
ASF GitHub Bot commented on TINKERPOP-1639:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/564
TINKERPOP-1639 Support simple String operations
https://issues.apache.org/jira/browse/TINKERPOP-1639
Added support for simple String operations. `CountLocalStep`,
`RangeLocalStep` and `TailLocalStep` can now imitate `String::length()` and
`String::substring()`.
A few examples:
```
gremlin> g.V().values("name").count(local)
==>5
==>5
==>3
==>4
==>6
==>5
gremlin> g.V().values("name").limit(local, 3)
==>mar
==>vad
==>lop
==>jos
==>rip
==>pet
gremlin> g.V().values("name").tail(local, 4)
==>arko
==>adas
==>lop
==>josh
==>pple
==>eter
gremlin> g.V().values("name").group().by(range(local, 1, 2)).next()
==>a=[marko, vadas]
==>e=[peter]
==>i=[ripple]
==>o=[lop, josh]
```
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1639
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/564.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #564
commit c6f92c9ef65fd711028b37745eed6e94e9163f0b
Author: Daniel Kuppitz
Date: 2017-02-24T10:13:53Z
Added support for simple String operations. `CountLocalStep`,
`RangeLocalStep` and `TailLocalStep` can now imitate `String::length()` and
`String::substring()`.
> Support simple String operations
>
>
> Key: TINKERPOP-1639
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.2.5
>
>
> Addd support for simple String operations, e.g. {{length()}} and
> {{substring()}}. The latter will also allow us to write {{startsWith()}} and
> {{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] tinkerpop pull request #564: TINKERPOP-1639 Support simple String operations
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/564
TINKERPOP-1639 Support simple String operations
https://issues.apache.org/jira/browse/TINKERPOP-1639
Added support for simple String operations. `CountLocalStep`,
`RangeLocalStep` and `TailLocalStep` can now imitate `String::length()` and
`String::substring()`.
A few examples:
```
gremlin> g.V().values("name").count(local)
==>5
==>5
==>3
==>4
==>6
==>5
gremlin> g.V().values("name").limit(local, 3)
==>mar
==>vad
==>lop
==>jos
==>rip
==>pet
gremlin> g.V().values("name").tail(local, 4)
==>arko
==>adas
==>lop
==>josh
==>pple
==>eter
gremlin> g.V().values("name").group().by(range(local, 1, 2)).next()
==>a=[marko, vadas]
==>e=[peter]
==>i=[ripple]
==>o=[lop, josh]
```
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1639
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/564.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #564
commit c6f92c9ef65fd711028b37745eed6e94e9163f0b
Author: Daniel Kuppitz
Date: 2017-02-24T10:13:53Z
Added support for simple String operations. `CountLocalStep`,
`RangeLocalStep` and `TailLocalStep` can now imitate `String::length()` and
`String::substring()`.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Created] (TINKERPOP-1639) Support simple String operations
Daniel Kuppitz created TINKERPOP-1639:
-
Summary: Support simple String operations
Key: TINKERPOP-1639
URL: https://issues.apache.org/jira/browse/TINKERPOP-1639
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.2.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Fix For: 3.3.0, 3.2.5
Addd support for simple String operations, e.g. {{length()}} and
{{substring()}}. The latter will also allow us to write {{startsWith()}} and
{{endsWith()}} filters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
