Re: [DISCUSS] Rethink JanusGrpah Schema Management

Ryan Stauffer <ry...@...>


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.


On Fri, Apr 5, 2019 at 7:41 AM <Jan....@...> wrote:


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:

Idea of an implementation order:

  1. Extract gremlin driver from JanusGraph core, so User only depend on small dependency to use JanusGraph with a gremlin client, like dot net or python GLVs.
  2. Make JanusGraph read only by using a tinkerpop strategy 
  3. Use a tinkerpop strategy to enforce the Schema
  4. Make the Schema accessible via gremlin

Any thoughts?



—— “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.

You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To post to this group, send email to janusgr...@....
To view this discussion on the web visit
For more options, visit

Join { to automatically receive all group messages.