Hi Boxuan, Happy to put in a request on github but still a little confused. Are we saying g.E().has('index_key', 'large_number_of_edges').hasNext() isn't streaming but should (note: g.E().hasNext()

Hi all, We faced below exception while creating vertex with custom vertex id. Issue did not reproduce steadily. Setup configuration is JG-0.6.0 + cassadra-4.0 in 3 node-single DC

Hi Matt, It will definitely be a valid and valuable feature, if we could expose the streaming capacity to end users. If I recall correctly, the low-level results are indeed streamed (it might vary

Hi Umesh, What you reported might be due to a different cause. Are you able to reproduce it steadily, and if so, could you please share the steps to reproduce the problem? It would be great if you

We faced below NPE with JG 0.6.0 while creating new vertex. Not sure if this is related but never seen this exception with earlier JG versions. java.lang.NullPointerException: null at

Hi Marc, All code and property configuration are shared in the last trail mail. I hope if we have not provided the cache properties then it means it will default false. Thanks, Pawan

Hi Boxuan, thanks for the response. Some background: I'm trying to use JG as a triplestore and importing rdf. The triple <microsoft> <rdfs:type> <company> can be modelled as V('microsoft') ->

Hi Matthew, Unfortunately, that is not possible. You could do g.V(v).inE(e).range(from, to).hasNext() to “page” the result by yourself, but under the hood, it will fetch all the first “to”

Hi, if we're creating graphs dynamically in JG are the limits like 2^60 edges and Global V and E indexes bound/scoped to the graph or bound across all graphs in the set of graphs managed by

Hi, I do need to traverse it but was hoping it would get chunked/streamed in. Or is there a better way for streaming/lazy loads?

Hi Mathew, I don't know what it does underneath. But if you want to just check about edge existence with hasNext, Can you try with limit 1. g.V(n).inE(e).limit(1).hasNext() Let's see, Amiya

Hey folks, I have a Vertex v who has about 7m+ incoming edges e. The following query takes about 30+ seconds on a local installation of

Duly noted. I'll keep in mind to dig deeper when seeing closed issues mentioning Tinkerpop updates. Thanks everyone!

Yes, exactly. This was a breaking change in TinkerPop 3.5.0 which is included in JanusGraph 0.6.0: https://tinkerpop.apache.org/docs/current/upgrade/#_anonymous_child_traversals Von:

Yes. In JanusGraph 0.6.0, Apache TinkerPop was upgraded to 3.5.1 and requires using an anonymous traversal in such cases. This is mentioned in their "Upgrade for users" guide here:

Ahh I see, I guess this is the intended usage now? Basically doing "__.V" instead of "g.V" for the child traversal?

When running with 0.5.2 I was able to do this traversal to add an edge between to vertices But when doing it through 0.6.0 I get this now: After fiddling with it though I noticed I was able to do

Hi Pawan, Interesting, I could not find a JanusGraph unit test for this basic scenario (there is one with two instances and an index, though). This needs more investigation. Meawhile, are you sure

Thanks for the clarification. That makes sense. I suppose if there were multiple edges from V(h) to V('mother') I would need to qualify it to insure the path exists? eg

Hi Mathew, Both of the example shows 2 different types of default index. g.V(h).out('mother') - This is example for default vertex-centric indexes per edge label - This will help to traverse specific