[DISCUSS] Rethink JanusGrpah Schema Management
Ryan Stauffer <ry...@...>
Circling back around on this. I'm going to dig into those two branches/features over the next few days Thanks, Ryan On Thu, Apr 11, 2019 at 11:30 AM 'Jan Jansen' via JanusGraph developers <janusgr...@...> wrote:
|
|
Jan Jansen <faro...@...>
Ryan, It would be cool to get some help. A good starting point would be make the graph readonly using a TinkerpopStrategy. This implemenation should be straight forward. My current state on task 3 and 4 are in following branches:
Thanks for your offer. Greetings Jan |
|
Ryan Stauffer <ry...@...>
Jan, I really like this overall approach and would love to lend a hand in making it happen. I like the idea of streamlining both schema management and general user access to a JanusGraph instance - I think this makes things much more "explainable" to other developers who need to access the database. Thanks, Ryan On Fri, Apr 5, 2019 at 7:41 AM <Jan....@...> wrote:
|
|
Jan....@...
Hi As a follow up to my talk last week, I would like to start a discussion on this topic about redesign the Schema Management.
General idea is to deprecated direct access to JanusGraph server using other things than a gremlin client/driver, such as the ManagementSystem or StandardJanusGraph.
Main advantage, we can change internally core components without having breaking changes in our front facing api.
I started to work on the first precondition to reduce the requirements to access a janusgraph instance using a java/groovy gremlin client/driver. PR: https://github.com/JanusGraph/janusgraph/pull/1521
Idea of an implementation order:
Any thoughts?
Greetings Jan
—— “We strongly encourage all users of JanusGraph to use the Gremlin query language for any queries executed on JanusGraph and to not use JanusGraph’s APIs outside of the management system.“ |
|