So "query building" is where you hold string representations of steps or
groups of steps and then have some logic that concatenates them together. I
guess my question is why are "strings" a requirement for that? It seems
like you could do the same query builder stuff with an actual Traversal
object in whatever Gremlin Language Variant you were working with. How is
string concatenation different than this:
gremlin> graph = TinkerFactory.createModern()
==>tinkergraph[vertices:6 edges:6]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> base = g.V().hasLabel('person');[]
gremlin> addFilters = { age, name, t ->
gremlin> t = age > 0 ? t.has('age',age) : t
gremlin> !name.isEmpty() ? t.has('name',name) : t
gremlin> }
==>groovysh_evaluate$_run_closure1@503d56b5
gremlin> traversal = addFilters(29,'',base);[]
gremlin> traversal.toString()
==>[GraphStep(vertex,[]), HasStep([~label.eq(person)]),
HasStep([age.eq(29)])]
gremlin> traversal
==>v[1]
What about DSLs? Maybe filtering logic drops behind a custom step specific
to the domain:
g.V().personsWith(29, '')
which would basically compile to the same thing as the gremlin output above:
[GraphStep(vertex,[]), HasStep([~label.eq(person)]), HasStep([age.eq(29)])]
Is there some more complex aspect "query building" that can't be handled
this way (I know I took a fairly simple example)?
On Wed, Apr 20, 2016 at 7:54 PM, Dylan Millikin <dylan.milli...@gmail.com>
wrote:
> I've approached this a few times in the past though never really in depth.
> The idea is that you want separation of logic in your queries, mostly for
> maintenance, testing and overall convenience. This takes the form of
> partial/incomplete traversals that have no start nor end.
> One of the simplest applications would be to have a base query and apply
> filters to this query. For example we can imagine a recap page of
> everyone's companies:
>
> base query : g.V().has(label, "person").out('company')
>
> To this you have a set of filters that are partial traversals and allow
> users to better refine their search:
>
> older than 30 filter: has("age", gt(30))
> male filter: has("gender", "male")
>
> Now depending on user input you'll want to apply either or both of the
> above to "person" in order to obtain something along the lines of:
>
> g.V().has(label, "person").has("age", gt(30)).has("gender",
> "male").out('company')
>
> Of course there are plenty of ways of doing the above depending on
> requirements and complexity. Such as where() or as("a")....select("a")
> etc..
>
> These are simple examples where steps are appended in various places but
> you can imagine the same with traversal manipulation such as turning
> out('company') into out('company', 'organization') where the step gets
> altered. This would work the same way if you used union(out('company'))
> instead. You would have to alter the union step like this :
> union(out('company'),
> out('organization'))
>
> All of the above are relatively simple but picture having a lot of very
> complex traversal "filters" that sometimes have dependencies on other
> filters.
> All this is doable but it currently requires looking at the gremlin
> building process as a query building one rather than native support for the
> gremlin language.
>
> Does that make any sense?
>
> On Wed, Apr 20, 2016 at 7:15 PM, Stephen Mallette <spmalle...@gmail.com>
> wrote:
>
> > > It's imperative that you have the ability to group multiline scripts
> > into a single query or the reactivity of your applications will greatly
> > suffer.
> >
> > A fair point and something we might yet address as part of all this
> > thinking. RemoteGraph is pretty new and it demonstrated a critical aspect
> > of communications with Gremlin Server. Now we need to think about how to
> > improve upon it.
> >
> > > Namely having the ability to edit/modify/add steps to an already
> defined
> > traversal.
> >
> > I don't quite follow that point...could you please elaborate?
> >
> >
> >
> >
> > On Wed, Apr 20, 2016 at 4:15 PM, Dylan Millikin <
> dylan.milli...@gmail.com>
> > wrote:
> >
> > > Nice post,
> > >
> > > I'm going to jump straight to the end. I think that one of the problems
> > of
> > > doing an abstraction similar to remoteGraph is that in reality the
> > overhead
> > > of communicating with the server is too big to make this viable. It's
> > > imperative that you have the ability to group multiline scripts into a
> > > single query or the reactivity of your applications will greatly
> suffer.
> > >
> > > The Gremlin-java base also has a few limitations that some query
> builders
> > > try to fix (which can only be done if you abandon the idea of a natural
> > > gremlin language variant in favor of a query builder). Namely having
> the
> > > ability to edit/modify/add steps to an already defined traversal.
> Though
> > in
> > > time it might be nice to have these be part of the original
> > implementation.
> > >
> > > I personally love the idea of gremlin language variants. I just don't
> > think
> > > they're production value is any good without some extended
> functionality
> > > (beyond what gremlin-java currently is).
> > >
> > > On Wed, Apr 20, 2016 at 3:23 PM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > > > This thread on Gremlin Language Variants has been very interesting:
> > > >
> > > > https://pony-poc.apache.org/thread.html/Zcazrw7k442xcwc
> > > >
> > > > I think that this work goes a long way to address two issues I've
> been
> > > > concerned about:
> > > >
> > > > 1. Greater consistency in how different languages do Gremlin
> > > > 2. Less fragmentation in terms of libraries and how they work so that
> > > users
> > > > aren't confused with how to get started (though I don't think the
> goal
> > > here
> > > > is to restrict choices or slow down innovation)
> > > >
> > > > One of the first things we should probably do is start thinking in
> > terms
> > > of
> > > > the types of libraries that are built on TinkerPop (outside of those
> > > things
> > > > that are Graph Systems) and those are listed here currently:
> > > >
> > > > http://tinkerpop.apache.org/#graph-libraries
> > > >
> > > > Marko mentioned to me that he saw the libraries we listed here
> breaking
> > > > into three categories:
> > > >
> > > > 1. Gremlin Language Variants - which the other thread demonstrates
> > quite
> > > > nicely
> > > > 2. Gremlin Drivers - the Gremlin Server protocol implementations -
> > those
> > > > things that send traversals to Gremlin Server and get back results.
> > > > 3. OGM and others - I say "others" because there might be plugins and
> > > other
> > > > similar odds and ends
> > > >
> > > > I like Marko's category system here and I think that having these
> kinds
> > > of
> > > > categories will help folks organize their libraries to fit into one
> of
> > > > these spaces and make it easier for users to know what they need to
> get
> > > in
> > > > order to start doing TinkerPop in their language.
> > > >
> > > > Anyway, the category thing is just setting the stage for this big
> > > > bombshell. I think TinkerPop should consider maintaining the Gremlin
> > > > Language Variants.
> > > >
> > > > Heresy! right?
> > > >
> > > > Well, I think it's the best way to achieve consistency across
> > languages.
> > > > Under this model, TinkerPop provides the base language variant and
> > people
> > > > can choose to extend upon it, but the base stays tied to our
> archetype
> > of
> > > > Java and we end up with a much more clear story for virtually any
> > > > programming language.
> > > >
> > > > So how do we do this? Slowly and deliberately. We should look to only
> > > > include language variants where we:
> > > >
> > > > + have good automation in place (like what Marko did for Python),
> > > > + some competence on the committer list in that language
> > > > + a nice testing framework that operates in our standard
> build/release
> > > > process.
> > > >
> > > > That's setting a high bar, but if we don't keep it high, I think we
> > will
> > > be
> > > > left unable to properly support and maintain what we hang out there.
> > > >
> > > > I'd also like to express that we should not be looking to maintain
> > > language
> > > > drivers. I think that should remain a third-party community effort
> just
> > > > like Graph Systems. In other words, we remain a repository for
> > reference
> > > > implementations for everything else. Why? Because, as it sits right
> > now,
> > > > just based on the level of effort for what Marko did with Python,
> > > > maintaining a "base" Gremlin Language Variants shouldn't be hard. We
> > > won't
> > > > be building tons of add-on capabilities to the base variants - they
> > will
> > > > pretty much just stay on par with the java archetype. Drivers on the
> > > other
> > > > hand have lots of implementation details, with many different
> > > technologies
> > > > that could be used, etc. They have similar complexity to Graph
> System
> > > > implementations in many ways. I also think that the drivers can
> afford
> > to
> > > > have different APIs and approaches without being detrimental to the
> > > > community.
> > > >
> > > > If gremlin-js-driver wants to do:
> > > >
> > > > client.submit("g.V()")
> > > >
> > > > and gremlin-python-driver wants to do:
> > > >
> > > > client.send("g.V()")
> > > >
> > > > that's not a big deal.
> > > >
> > > > The last point that I'll make is that I think Gremlin Language
> > Variants,
> > > > that don't operate on the JVM (e.g. Jython) and use Gremlin Server,
> > > should
> > > > have some abstraction that is similar to RemoteGraph. RemoteGraph
> > > exposes
> > > > a DriverConnection interface that is currently implemented by
> > > > gremlin-driver. The DriverConnection is responsible for sending a
> > > > traversal to the server and returning results. It would be nice if
> the
> > > > language variants had a similar interface that the various community
> > > > drivers could implement. In that way, the user never has to do any
> form
> > > of:
> > > >
> > > > client.submit(someGremlinString)
> > > >
> > > > in any language. We really need to try to make that pattern go away
> > > across
> > > > the TinkerPop community.
> > > >
> > > > So - that's was a long email. Looking forward to hearing some
> > discussion
> > > on
> > > > this.
> > > >
> > > > Stephen
> > > >
> > >
> >
>
