Here's the issue related to nesting repeat() steps:
https://issues.apache.org/jira/browse/TINKERPOP-967
it's not clear from the comment where marko left that one exactly. anyway,
i'm not aware of anyone actively working on that.
On Thu, Feb 15, 2018 at 1:50 PM, Moore, Branden James
wrote:
> >
> Out of curiosity, what graph database are you using?
We're using Neo4j as our underlying database, though we have no strong
attachment to it.
Are there roadmap plans to supporting nesting loops? (ie, a repeat under a
repeat)
On 2/15/18, 10:15 AM, "Stephen Mallette" wrote:
Coo
Cool. I flip/flop back and forth about having better support for general
predicates (like text and geo) - seems like this would be a argument in
favor of adding such things to resolve this problem of having to write
server side DSL code. if done right it might save graph providers from
having to wr
>Can you talk about what those custom steps do? Do you also have custom
> TraversalStrategies which interact with them?
We do not have any custom TraversalStrategies yet.
We do have custom predicates, though not many... Mostly string operations
(textContains, textRegex).
Most of our cus
> Do you expect to *NOT* support server-side DSLs in the future (even as
Bytecode)?
I think that's it's a bit early to say that definitively, but all community
discussion thus far has pointed in the direction of keeping DSLs a
client-side construct, so I'd expect that we would not do much work to
Now that python-gremlin is mature enough to use and extend, I'm working to
migrate our environment to a fully session-less, bytecode-based environment.
However, we currently have significant amounts of "legacy" groovy/gremlin
hanging around. Until all of that can be migrated, we still need to
> Perhaps if there was a way to specify a custom "__" class to the
ImportCustomizer, this would all solve itself?
yes - it might. i don't think we should go down that path though. first of
all, i think the workaround i suggested seems like the way to do this
within the context of what we have rig
I think I figured out why 'label' isn't getting imported... It is being
overwritten in the import map by the __.label() method static import.
Normally, the CoreGremlinPlugin imports 'T.label' and '__.label()' is filtered
out of the imports on line 59 of ImportGroovyCustomizer.java (It was
Sorry - those imports are really mysterious to me. I dug through a fair bit
of groovy code trying to figure out what the rules were for that import
stuff and i don't recall getting to the bottom of it.
On Wed, Feb 14, 2018 at 2:27 PM, Moore, Branden James
wrote:
> So I did a quick experiment of:
So I did a quick experiment of:
---
a/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
+++
b/gremlin-groovy/src/main/java/org/apache/tinkerpop/gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
-
CoreGremlinPlugin.instance().getCust
There was a time when I looked into that in pretty grave detail. I don't
recall my findings exactly, but I obviously didn't come up with a nice
solution. I'm not sure that I ever became convinced that any of this groovy
import stuff behaves in a completely deterministic way. I suppose you could
try
Thanks for fixing issue #1. I figured that one would be easy to fix.
As for issue #2, I'm wondering if changing the GremlinGroovyScriptEngine to add
it's ImportCustomizer (line 247) to the beginning of the list of customizers,
rather than the end, would allow DSLs (and any other imports) to o
12 matches
Mail list logo
