Hi, Stephen, Before I send out an email to the broader dev mailing list, can you take a look to see if the following project complies with TinkerPop's listing policy?
https://github.com/karthicks/gremlin-ogm Currently, it has one release based on TinkerPop 3.2.5. Also, I created the following issue to investigate whether the library will work with remote traversals: https://github.com/karthicks/gremlin-ogm/issues/1. Regards, Karthick On 2017-08-15 11:25, "Karthick Sankarachary"<[email protected]> wrote: > 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 > > > > > > > > > >
