> "my query fails on Graph DB XYZ but works on unmodified TinkerGraph"
I can't remember if that was another concern or not, but note that I may not have been clear - the intention isn't to make it so TinkerGraph can take extensions by way of plugins but by allowing folks to extend from the various Java classes that TinkerGraph exposes (which are all currently marked as "final"). So "extensible" really just means class inheritance in the classic object-oriented definition. Perhaps that additional context answers your other questions. On Thu, Sep 10, 2020 at 6:44 PM Kelvin Lawrence <[email protected]> wrote: > In general if people see a need for an extensible TinkerGraph and want to > avoid making forks it seems a reasonable ask. My only slight concern might > be that we lose the strong likelihood that when a user says something like > "my query fails on Graph DB XYZ but works on unmodified TinkerGraph" that > there is an issue with the other implementation has or at least some > conscious deviation from the "reference implementation". So we will have to > get used to asking "have you applied any extensions?". Other than that, if > people have good use cases for wanting to extend TinkerGraph I can't think > of other reasons right now to say it is a bad idea. > > Would the extension mechanism you envisage allow for graph providers to > customize TinkerGraph to better mirror their implementation's behavior - > without needing to fork it? In one case I can think of, perhaps a provider > does not support all Gremlin steps yet for some reason but wants to enable > easy development and testing using TinkerGraph for their users. Or would > you perhaps see that as violating the API contract that final was used to > protect? > > On 2020/09/10 11:33:07, Stephen Mallette <[email protected]> wrote: > > Should TinkerGraph be extendable? This is not a new discussion. Most> > > notably, Michael Pollmeier long ago wanted to allow for this to> > > experiment with a TinkerGraph fork where he used schemas to drastically> > > increase the performance:> > > > > https://github.com/ShiftLeftSecurity/tinkergraph-gremlin> > > > > which then was replaced by the quite neat:> > > > > https://github.com/ShiftLeftSecurity/overflowdb> > > > > To the best of my knowledge, the argument against making TinkerGraph> > > extendable has been that allowing extension of TinkerGraph would create> > > situations where we felt we couldn't alter TinkerGraph APIs and > behaviors> > > as easily as we would like and wanted to maintain the flexibility to > change> > > what we wanted when we wanted without fear of breaking those extending > it.> > > > > Since those early discussions to come to that reasoning many years ago,> > > I've learned that TinkerGraph has a lot of interesting usages that you> > > normally wouldn't think of. I've seen/heard it used internally within > graph> > > systems quite regularly. This might be for testing or functional > purposes> > > and there are times when being able to extend it would be quite handy > where> > > a fork of TinkerGraph would be too heavy handed. I've also come to the> > > realization that in our current times, TinkerGraph is quite stable in > terms> > > of API and behavior (the two things we've wanted to protect with > "final"> > > modifiers). There are few changes, the last major one probably relates > to> > > the introduction of null support in 3.5.0 almost 12 months ago.> > > > > Given these realizations and another recent request to "remove a final" > in> > > TinkerGraph, I've started to wonder if the reasons we had many years > ago> > > still hold and am inclined to think that they do not. Does anyone have> > > thoughts on the matter?> > > > > As an aside, it's interesting that when a project lives long enough, > the> > > decisions that felt like absolutes begin to feel a bit more mutable. > For> > > example, for years we thought we'd never maintain Gremlin in other> > > languages in our repository, but now we hold many languages here and > GLVs> > > are highly popular in what they allow. Sorta thought provoking....> > > > Cheers, > Kelvin > > >
