by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Florian Hockmann
    @FlorianHockmann
    Wow, we now don't have any janusgraph-cassandra module in the main repo after #2095 is merged :tada:
    Thanks a lot, @farodin91, for cleaning this up :+1:
    Jan Jansen
    @farodin91

    Hi
    Started to work on Grpc based replacement of the ManagementServer, I want to show you my current state to get some feedback. I have to add "how to use".
    Repo: https://github.com/farodin91/janusgraph-grpc

    This Code also wrappers the GremlinServer and GremlinServer.Settings. In this way, I'm able to start the gremlin server and grpc server at same. Moreover, I can ensure default settings values for serializers. If you update the JanusGraph Server and never changed any of those settings you get a correct default with all serializers of JanusGraph.

    The Grpc server allows you to access multiple graphs using a context which can be helpful, if your are using the ConfigureGraphFactory.

    Next step add more functionally to server, write a client and add some examples.

    Any thoughts?

    31 replies
    Debasish Kanhar
    @debasishdebs
    image.png

    image.png

    When I ran gradle build --info

    Jan Jansen
    @farodin91

    image.png

    I have to fix this issue.

    Oleksandr Porunov
    @porunov
    Hi, I would like to prepare 0.5.2 short after JanusGraph/janusgraph#2103 . Let me know if you think we should include some other contributions in 0.5.2 or if there is a reason to delay this release.
    Jan Jansen
    @farodin91

    Hi, I would like to prepare 0.5.2 short after JanusGraph/janusgraph#2103 . Let me know if you think we should include some other contributions in 0.5.2 or if there is a reason to delay this release.

    I don't think we have any blocker for this release.

    Oleksandr Porunov
    @porunov
    Committers approval is needed for 0.5.2 release commit. All TP tests passed. JanusGraph/janusgraph#2108
    Oleksandr Porunov
    @porunov
    Sonatype405.png
    Oleksandr Porunov
    @porunov

    Unable to deploy artifacts to Sonatype. Unable to open staging repositories. The error returns: Nexus returned an error: ERROR 405: Method Not Allowed. Attached screenshot above. When trying to deploy artifacts with the command mvn clean javadoc:jar deploy -Pjanusgraph-release -DskipTests=true it returns:

    [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project janusgraph: Failed to deploy artifacts: Could not transfer artifact org.janusgraph:janusgraph:pom:0.5.2 from/to ossrh (https://oss.sonatype.org/service/local/staging/deploy/maven2/): Failed to transfer file https://oss.sonatype.org/service/local/staging/deploy/maven2/org/janusgraph/janusgraph/0.5.2/janusgraph-0.5.2.pom with status code 405 -> [Help 1]
    [ERROR] 
    [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
    [ERROR] Re-run Maven using the -X switch to enable full debug logging.
    [ERROR] 
    [ERROR] For more information about the errors and possible solutions, please read the following articles:
    [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

    If anyone knows what could cause the problem, please, share your thoughts. I didn't change the releasing flow. As seen from the screenshot, I cannot access staging repositories using UI right now.
    I guess either something changed in Sonatype or I lost permissions to access repository or there is a temporary problem in Sonatype OSS.

    Oleksandr Porunov
    @porunov
    Looks like it was a temporary problem on Sonatype side.
    The issue is now resolved and is not reproducible.
    The artifacts are now uploaded correctly and staging repositories can be accessed.
    Oleksandr Porunov
    @porunov
    JanusGraph 0.5.2 release VOTE is started here: https://groups.google.com/forum/#!topic/janusgraph-dev/T9d20Hx9Kgc
    Debasish Kanhar
    @debasishdebs

    @farodin91 : Quick question. I'm planning to connect the server to a BerkleyDB instance with GraphOfGods loaded already. Do all GET opeartions on it, make it work then move to PUT operation from Client side. (Accordingly we can also find out which feature is missing from Server).

    The current grpc server which embeds gremlin server, does it also expose multiple contexts/janusgraphs defined in .YAML file or does it take single (the last key:value pair in Map) ?

    So, if I expose g and g1 from gremlin server based on graphs map property, I can initialize the context as request.set_context('g1'); request.set_context('g') .. and so on similarly while querying the grpc server to do different set of operations on different Graphs right?
    Debasish Kanhar
    @debasishdebs
    Because I'm looking at core.server.DefaultJanusGraphManager and core.server.JanusGraphServer and not seeing any Map<String, String> to initialize StandardJanusGraph
    Debasish Kanhar
    @debasishdebs

    Okay @farodin91 : The issue is resolved. Loaded GraphOfGods and I'm able to do GET on on existing VertexLabels and EdgeLabels. Able to add more VertexLabel using EnsureVertexLabelRequest. I'll be expanding client to support more operations. Currently it supports only following:

    1: GET - VertexLabel - ALL
    2: GET - VertexLabel - Name
    3: GET - EdgeLabel - ALL
    4: GET - EggeLabel - Name
    5: PUT - VertexLabel - Name [Only with defaults]

    WIll be adding support for variations as well :-)

    Jan Jansen
    @farodin91
    Cool to hear that you solved most of your question. My client was just to test that I'm able to connect with client.
    ((name)string, (config)string) can be found https://github.com/farodin91/janusgraph-grpc/blob/master/src/main/kotlin/org/janusgraph/core/server/DefaultJanusGraphManager.kt#L238 here.
    I'll improve the ConfiguredGraphFactory as next. So, I'm able to contribute the JanusGraphServer with default configuration.
    so on similarly while querying the grpc server to do different set of operations on different Graphs right? If you use ConfiguredGraphFactory, you'll able to access an manage multiple graph at same time.
    1 reply
    Jan Jansen
    @farodin91
    @debasishdebs I improved the index support.
    Debasish Kanhar
    @debasishdebs

    Great @farodin91 . Well I was able to test following scenarios now:
    1: GET CompositeIndex on VertexLabel w/o INDEX_NAME
    2: PUT CompositeIndex on VertexLabel

    I've few concerns like I don't think server supports scenario like
    1: GET CompositeIndex ALL_LABELS (Vertex/Edge) w/o INDEX_NAME
    2: GET CompositeIndex ALL_LABELS (Vertex/Edge) with INDEX_NAME
    3: PUT CompositeIndex ALL_LABELS (Vertex/Edge)

    11 replies
    I'll verify if the above mentioned scenarios are covered, and if not, how can we cover those. I'll check out the code and let you know. Accordingly either you can add the support on Server side or I can whichever we decide. :-) Let me pull your recent version of master and verify if the support is still absent or not
    Debasish Kanhar
    @debasishdebs
    @farodin91 : Added support for directed in EdgeLabel message. Added support for recoginzing when multiplicity and directed is passed while creating EdgeLabel in ManagementForEdgeLabels.kt files. You can have a look at my branch index-support in my fork and if you plan to develop those, you can sync up with my branch :-)
    Jan Jansen
    @farodin91
    @debasishdebs Cool, I'll checkout your changes.
    Debasish Kanhar
    @debasishdebs

    @farodin91 : Have created a PR. It contains Readme on how to invoke APIs from Python client. Quick question is, how do you plan to integrate this with Client? Do we plan to create a GraphQL on top of it for API Access?

    Or, we want to create a DAO type access layer in native language (like python for eg) which shares the same syntax as we have in Java management system, and it calls underlaying gRPC Clients and its Services in backend based on what management query is constructed?

    Something like:

    mgmt = JanusGraph().connect().openManagement()
    mgmt.makeVertexLabel().static().make()
    mgmt.makePropertyKey().dataType().make()
    
    and so on

    As you can see above those are proposed syntax for Python client which shared a highly similar format to Java client. Since we don't expect users to call the gRPC Client stub manually to create Schema elements, having a similar syntax structure to existing JVM systems will help them port easily across languages.

    If you also agree, I can next get started working on these DAOs with the existing implementations of Client we have. What do you say? Also looping in @FlorianHockmann

    In end we will have 2 possible ways for non JVM users to access ManagementSystem either using a GraphQL [On top of gRPC as proposed in [ https://groups.google.com/forum/#!topic/janusgraph-dev/kf21jGgWNn8 ]] and via GLV/DAO from native language mentioned above.