Hi, Stephen,
Thank you for sharing your feedback on my pull request. In hindsight, I should
have vetted this idea on the dev list first, and I apologize for that. As
suggested,
I'll let gremlin-objects develop on it's own, and see if gains any traction.
Before I publish that stand-alone project, I'd like to take this opportunity to
address some of the concerns you brought up, if I may:
1) While it does introduce new object-centric Graph and Query interfaces,
the goal there was to simply facilitate the object-gremlin mapping. The
traversals are specified as lambdas, such as `g -> g.V().count()` or
`traversal -> traversal.count()`, etc. As far as the provider interface, I
think I might be able to get rid of it, on second thoughts. All I really need
is a GraphTraversalSource. I may have to get rid of the ability to execute
scripts (traversals inside strings), but that'd be a small price to pay.
2) Pardon my ignorance, but can you share the Javadocs for the remote
traversals API, as I'm not familiar with it? I can then evaluate whether I can
support that or not. Also, can you elaborate what you meant when you said
"elements don't hold properties"? When I look at the core Vertex, Edge, and
Element interfaces, it does hold properties.
3) I share your concern that if we had to port this across languages, it would
be a non-trivial task (even without the comments, its 2905 lines of main code,
and 2354 lines of test code). Having said that, if we were to assume that the
GLV is supported through JSR-223, then there's a chance that gremlin-objects
will work for that GLV. I'll try and do a proof of concept for that in the
separate
project specifically for Gremlin-Python.
4) The intent of this module wasn't to compete with the DSL paradigm. I believe
that the two can co-exist. Let me try and illustrate that with this example:
List<Friend> friends = query.by(
g -> g.V().find(marko).friends(4)).list(Friend.class);
where, "g" was obtained through graph.traversal(FriendsTraversalSource.class);
Again, the module focuses on object mapping, and gets out of the way when
you want to specify traversals. It does provide a library of helper traversal
functions based on objects, but again, it complements rather than competes.
5) I understand why you wouldn't want to pick any given OGM as the standard
one, given that you listed so many, some of which I haven't even heard of, to
be honest.
Again, thanks for sharing your feedback - it was very valuable for me. Once I
incorporate some of the suggestions and concerns into my module, I'll publish
the lin, and hopefully you can put it up on TinkerPop home page. I'm looking
forward to seeing this gaining traction, and adding support for it, as needed.
Best Regards,
Karthick Sankarachary
https://www.linkedin.com/in/karthicksankarachary
On 2017-08-15 05:33, Stephen Mallette <[email protected]> wrote:
> Some of you may have noticed this PR:
>
> https://github.com/apache/tinkerpop/pull/693
>
> It is for an object graph mapper. It is fairly large and, at a glance, a
> nicely developed body of work (docs, tests, javadoc, etc). As the author
> didn't bring this up on the dev list before issuing the PR, I'm unsure of
> their intentions, but I assume they would like gremlin-objects to be the
> standard OGM for TinkerPop.
>
> Without drilling too deeply, my immediate concerns with accepting this into
> the code base:
>
> 1. It promotes use of a method of development that seems in competition to
> the Traversal API rather than one that complements it. For example, it adds
> a new Query object and uses Structure API semantics. It also adds new
> interfaces for providers to implement if they want to support this feature.
> 2. I'm not clear on how well this approach would support remote traversals
> especially since we discourage Elements from being returned with
> properties.
> 3. The author admitted that this is a Java only solution. Given the size
> and complexity of this PR I'd be concerned about trying to implement it
> across languages. Our general design goal has been to keep GLVs simple.
> Recall again - elements in GLVs don't hold properties at all - it's not
> even an option.
> 4.I tend to see DSLs and OGMs linked a bit in terms of what they do. DSLs
> are new - just one version old. I'd like to seem them develop a bit longer
> and get some feedback on usage to see how they address users problems for
> writing Gremlin in their domains.
> 5. If we accept this, we are saying that this approach to OGM (and there
> have been a number of them, Ferma, Peapod, Frames, etc.) is the "right" way
> and as of right now I'm not sure I'm willing to get behind that. I tend to
> think there are many ways to OGM and that different people will like
> different ways - this is largely the reason why we tend not to focus our
> development in this area.
>
> I think I'd like to see gremlin-objects develop on its own for a while
> separately, build its own community following, and work out whatever rough
> edges it may have. TinkerPop would add it to the tool listing on the home
> page and promote it as an option for those looking for an OGM. We've had
> this recommendation before to other pull requests and project suggestions
> and I think it tends to work out well for all parties.
>
> For those reading this not familiar with our processes, this is just my
> opinion on how we should move forward. Others may not feel this way. Please
> feel free to share your thoughts.
>
> Thanks,
>
> Stephen
>
