Hi, Stephen, Once I make sure the project satisfies the listing policy, I will email it to the dev list for your approval.
Thanks again! Karthick Sankarachary On 2017-08-15 10:29, Stephen Mallette <[email protected]> wrote: > 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 > > > > > >
