Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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.

    Jan Jansen
    @farodin91

    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?

    I don't will build an graphql on top of it from JanusGraph site. It would prefer client lib to integrate with this api.

    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?

    I don't think we should use the same syntax in each language. each language has a different styling.

    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.

    My plan is to remove this part after grpc client and server is integrate because the ManagementSystem is not the best code.

    GLV part as mention from me in the group would be hard would take a long time.
    Debasish Kanhar
    @debasishdebs

    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?

    I don't think we should use the same syntax in each language. each language has a different styling.

    Makes sense. But if we plan to use diff syntax for different languages, then won't that be another huge discussion forum and we will need to design the synax from scratch up. That would be lots of work I feel. If we have something like existing ManagementSystem based styling, we have some ground work already and we can use some elements from there while add few from our own so that saves up lot of time in designing aspect. What do you think?

    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.

    My plan is to remove this part after grpc client and server is integrate because the ManagementSystem is not the best code.

    So the current client in Rust is just for testing purpose is it? Cool. Well my Python client I'm developing I want to re-use this later while building management system / schema system in Python. Hence wanted some sort of dicsussion on that.

    Debasish Kanhar
    @debasishdebs

    GLV part as mention from me in the group would be hard would take a long time.

    Yes, correct as it would include lot of components :-) But we can get started with some sort of DAO/GLV.
    So, I've been able to complete following syntax today from Python and verified it works through unit tests. :

    mgmt = JanusGraphManagement().connect(self.HOST, self.PORT, self.GRAPH)
    edges = mgmt.makeEdgelabel(default_label).make()
    edges = mgmt.makeEdgelabel(default_label).undirected().make()
    edges = mgmt.makeEdgelabel(default_label).multiplicity("Many2One").undirected().make()
    edge.getLabel()
    edge.getMultiplicity()
    edge.getDirected()
    edge.getDirection()
    
    vertex = mgmt.makeVertexLabel(default_label).make()
    vertex = mgmt.makeVertexLabel(default_label).setStatic().make()
    vertex = mgmt.makeVertexLabel(default_label).partition().make()
    vertex.getLabel()
    vertex.getStatic()
    vertex.getPartitioned()

    Ultimately I want all of us to decide on the set of Syntax we want to follow, so that some similar DAOs can be created for user to do Schema actions from their native language. Reason for keeping all syntax acoss language close to similar is for a user to achieve interportability without going through much of docs and making life easier :-)

    Jan Jansen
    @farodin91

    Reason for keeping all syntax acoss language close to similar is for a user to achieve interportability without going through much of docs and making life easier :-)

    Sure. From my point of view, we should start again recreating a api which is shared cross system, more like a green field.

    The code the of ManagementSystem so hardly couple with internal code, so I can't change it without creating huge breaking changes. Therefore, i started to create a new schema interaction endpoint (grpc). So, we can refactor the code much easier in the backend without making breaking changes on the user side.

    Debasish Kanhar
    @debasishdebs

    Yea. And per my view, as a good starting point we would need to enable following set of features as initial point so as to make it usable with bigger community in my view:

    1: Create Property Key bound and unbound to any vertex/edge label
    2: Get property key, either bound to labels (Get with respect to label) or unbound.
    3: Create Vertex/Edge labels with or without constrained property keys
    4: Get Vertex/Edge labels
    6: Create composite index, either constrained to single label (Single or multi properties) or un constrained to any label
    7: Get Composite indices.

    So, I would suggest, as course of action, let's create grpc server to support above as those set of features would cover lot of gerenic use case. What do you say? I can get working on fill up the missing gaps from ur grpc server (like 1 and 2/6) and you can get working on getting grpc server into official Janus. That way we both can work in parallel and make this happen. What do you suggest @farodin91 ?
    3 replies

    The code the of ManagementSystem so hardly couple with internal code, so I can't change it without creating huge breaking changes. Therefore, i started to create a new schema interaction endpoint (grpc). So, we can refactor the code much easier in the backend without making breaking changes on the user side

    Yea, that's what I though as well the reason for creating grpc server that the current ManagementSystem APIs are really complicated. My question is, as I went through existing server code, the Server makes use of JanusGraphManagement APIs itself to do any sort of Schema action. How do you plan to replace that? Or we want to make accessibility of JanusGraphManagement system internal, not expose it to outside world?

    1 reply
    Debasish Kanhar
    @debasishdebs

    And, as you mentioned, any changes to ManagementSystem APIs beings in breaking changes, is the following course of action you think we need to take?
    1: Create server,
    2: Make users start migrating to usage of grpc instead of creating schema directly using ManagementSystem
    3: Slowly start changing the Managemen system while also at same time changing the usage/APIs in grpc?
    4: So that we can slowly keep updating grpc server without user knowing what changes happening inside. Is that what you envision?

    Also, we will need to start a post [DISCUSS] I guess to decide on query framework from scratch up for our new client to be built don't you think? I think all these things will take long time, maybe months :-)

    1 reply
    Boxuan Li
    @li-boxuan
    Hi, does anyone know the difference between cla:yes and cla:external labels in PRs? Does this have anything to do with ICLA vs CCLA?
    3 replies
    GeorgeHon
    @GeorgeHon
    Hi, i had fix an serializer issues , when user set accept application/vnd.gremlin-v2.0+json it throws org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0 cannot be cast to org.apache.tinkerpop.gremlin.driver.ser.MessageTextSerializer, cloud anyone give me a review?
    this is the [detail link] (JanusGraph/janusgraph#2151)
    GeorgeHon
    @GeorgeHon
    hi ,about the jansugraph , Does it has roadmap or some feature plan?
    2 replies
    wangweidonghb
    @wangweidonghb
    Operation cannot be executed because the enclosing transaction is closed
    I encountered the above error when executing a very regular query.
    Can some one help me ?
    图片.png
    I printed the above two query statements in the figure. The first query in the figure reports an error while the second query can be executed normally.
    wangweidonghb
    @wangweidonghb
    The difference between them is only in the value of the ‘status’ parameter.
    karthick-techiee
    @karthick-techiee
    Hi, Am running docker container using
    docker run --rm --name janusgraph-default -p 8182:8182 -v $HOME/docker/volumes/janusgraph:/var/lib/janusgraph janusgraph/janusgraph:0.5.2
    My aim is to load groovy file while staring the gremlin console using
    docker run --rm --link janusgraph-default:janusgraph -e GREMLIN_REMOTE_HOSTS=janusgraph -it janusgraph/janusgraph:0.5.2 ./bin/gremlin.sh -e path/to/file/sample.groovy
    But, gremlin console start failed saying that Gremlin file not found at <path/to/file/sample.groovy>
    Can anyone help me with how to resolve this issue?
    Hitesh Bothra
    @hiteshbothra

    Hi
    I am new to janusgraph.
    Can someone please explain how to query janusgraph in distributed manner.
    My use case is to find details of all the connected components.
    g.withComputer().V().connectedComponent().group().by(ConnectedComponent.component).unfold()

    I am using above gremlin query to get the connected vertices.

    Boxuan Li
    @li-boxuan
    @/all https://summerofcode.withgoogle.com/ Google Summer of Code 2021 programme was just announced. Any interest in joining as an organization?
    Queal
    @queal
    range() method, offset more big the response more slow, Can some one help me (janus-server embedded, hbase, es)
    Jan Jansen
    @farodin91

    @/all https://summerofcode.withgoogle.com/ Google Summer of Code 2021 programme was just announced. Any interest in joining as an organization?

    Do you want to start a disscussion on github?

    Boxuan Li
    @li-boxuan
    Yeah sure, sounds good
    Razi Kheir
    @raxelz
    Hi everyone,
    My name is Razi, i've been working on a graph service for a month now attempting to use JanusGraph
    Current setup: My service -> Janus/Gremlin -> Cassandra (Disk)
    When running on metal, I get relatively good performance, but as soon as I switch to docker compose example, the performance goes down 10x and response time goes up
    I have been attempting to find the issue through different monitoring but I cant find it.
    Docker Resource Spec: 16 cores / 28 GB Mem/ 128 GB SSD
    Janus Config: CQL / 16 Workers / 32 Janus Pool
    Service Config: 300 Max connection pool size
    Did anyone run into this issue? Its been sometime while investigating, its getting gnarly
    Paras Chhabra
    @paraschhabra96

    Hello Everyone!

    Is there any good resource to understand how janusgraph stores data in cql ?

    Data inside cassandra is stored in blob format and is not human readable. My purpose for understanding this is so that I can carry out some migrations like changing a property name, adding new property etc directly through cassandra and not through janusgraph. Any documentation on how the data is serialised and deserialised would be very helpful. Thanks.

    Oleksandr Porunov
    @porunov
    JanusGraph v0.5.3 voting process is opened here: https://groups.google.com/g/janusgraph-dev/c/MV0rgc4fXD4
    chandramouli-m
    @chandramouli-m
    We have a graph of few million vertices and edges and my current gremlin query is quite long . On profile its traversing over 50k and I see lot of backend_query steps. Can someone suggest what options I have to optimize performance
    Oleksandr Porunov
    @porunov

    JanusGraph now accepts donations via LFX Crowdfunding.
    The announcement is available here: https://lists.lfaidata.foundation/g/janusgraph-announce/topic/announcement_janusgraph/84454614
    Donations link: https://crowdfunding.lfx.linuxfoundation.org/projects/janusgraph

    Best regards,
    Oleksandr Porunov
    on behalf of JanusGraph TSC

    Lewis Chan
    @baiwfg2
    @farodin91 Hi, would you give some guidance on how to setup JG 0.5.2 + adapter 0.1.0 + FDB 6.2.22 environment ? See JanusGraph/janusgraph-foundationdb#54
    subbu165
    @subbu165
    @FlorianHockmann -- we have Janus-Graph with back-end store Foundation DB and index back-end as Elastic Search. Please let me know what is the best way to export/read Millions of Records from JaunusGraph by keeping performance in mind. We don't have the option of using Spark in our environment. I have seen 100s of articles on Bulk Loading but not bulk export/Read. Any suggestion would be of a great help here.
    Oleksandr Porunov
    @porunov

    The JanusGraph Technical Steering Committee is excited to announce the release of JanusGraph 0.6.1.

    JanusGraph is an Apache TinkerPop enabled property graph database with support for a variety of storage and indexing backends. Thank you to all of the contributors.

    The release artifacts can be found at this location:
    https://github.com/JanusGraph/janusgraph/releases/tag/v0.6.1

    A full binary distribution is provided for user convenience:
    https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-full-0.6.1.zip

    A truncated binary distribution is provided:
    https://github.com/JanusGraph/janusgraph/releases/download/v0.6.1/janusgraph-0.6.1.zip

    The online docs can be found here:
    https://docs.janusgraph.org

    To view the resolved issues and commits check the milestone here:
    https://github.com/JanusGraph/janusgraph/milestone/22?closed=1

    Thank you very much,
    Oleksandr Porunov

    nidhi-s-vinaykiya
    @nidhi-s-vinaykiya
    @porunov @farodin91 I am using Janusgraph 0.5.2. How can I get rid of log4j vulnerability that 1.2.x has? Will 0.5.2 support log4j 2.17.x [Maybe install the binary of log4j 2.17.x] ? Or do we have any other log4j alternatives that janusgraph 0.5.2 can support? If yes, do we have a document on how that can be integrated with Janusgraph?
    nidhi-s-vinaykiya
    @nidhi-s-vinaykiya
    @li-boxuan