Hi Karthick - thanks for joining the thread and thank you for understanding the position I took. Let me try to respond to your questions:
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. > I think that "scripts' will one day (no time soon) be a dead notion in TinkerPop. We actively try to discourage the pattern now that we understand how Gremlin bytecode and GLVs work, but I'm sure there is a lot of production code out there that relies on "scripts". For the purpose of your project i'd agree that losing scripts is a small price to pay and in line with the general TinkerPop direction. > 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. > I'm talking about GLVs and remoting: http://tinkerpop.apache.org/docs/current/reference/#connecting-via-remotegraph http://tinkerpop.apache.org/docs/current/reference/#gremlin-python there should be another link here for gremlin-dotnet but we're struggling with doc generation atm, but hopefully you get the idea. your examples seemed to require an embedded Graph instance, whereas remoting enables traversals to be converted to bytecode, shipped to gremlin server, with results returned from there (i.e. the Graph instance isn't embedded but remote). Key to this point is that when you do g.V() with remoting you don't get back properties. You get back a "reference" vertex which only has the id and label - no properties. We've come to agree that not returning properties is important for a number of reasons, not the least of which is multi-properties - imagine you returned a vertex with a million properties on it. 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. > Yes - I would think that JVM projects could make use of gremlin-objects. It's one of the reasons we don't have gremlin-scala or Ogre in TinkerPop. Those languages can all easily work with existing TinkerPop Java libraries as their cornerstone. Gremlin-Python exists in TinkerPop as we wanted to support Python natively - i don't think many folks want to run python in the jvm. 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. > I guess I could see that I suppose. I didn't have anything in mind in particular when I wrote that. I think I'd just want to be sure we always have "less ways of doing things" rather than "more". TinkerPop sometimes produces too many ways to do the same thing and it causes confusion and almost always leads to people doing things we didn't intend. > 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. Sure - our listing policy is here: http://tinkerpop.apache.org/policy.html I think that you satisfy most of that - I think you just need an official release published to get listed. Just send an email to this list letting us know that you meet the policy requirements and would like to be added. I think your project will make a nice contribution the wider TinkerPop Community. Stephen On Tue, Aug 15, 2017 at 1:05 PM, Karthick Sankarachary <[email protected]> wrote: > 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 > > >
