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

Hi Amiya, I saw that but wasn't quite sure the intent given the example. It talks about edge labels but the examples are vertices & values? g.V(h).out('mother') -> returns a vertex

Hi Mathew, As per the below Note from Janusgraph docs, even if company is having 1k different types of edge related to it, traverse by edge lable will be fast. Such as find employees employedBy (edge

Hi Matthew, It would be possible to replace the employedBy, isSoldby, isLeasedBy relations with a relatedToCompany relation with employment, selling and lease properties. But I do not see any

Hi, I am trying to build a triplestore ontop of JG. The general model is: Vertex (subject or object) Properties: Label Value (IRI, Literal) - indexed Edge (predicate) Properties: Label

Hi Marc, Thanks for your suggestion, However I am testing it on a local environment having a single replication factor. I believe if the replication factor is one then in all cases it should give me

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

Hi Tendai, "Not serializable" sounds as if you pass a JanusGraph instance from the Spark driver to the executor. The function that runs on the Spark executor should call some static function on the

Hi Marc, Thanks for the feedback and suggestion. We investigated applying the JanusGraphFactory inside a singleton object as you've suggested, but ran into the issue that the JanusGraphFactory is not

Hi Pawan, You are right, if issues already arise without index, you should investigate that first, even though a large graph without indices is useless in itself. See the third question from Boxuan Li

Hi Marc, Thanks a lot for looking into this. As requested, I filled an issue about this on Github: https://github.com/JanusGraph/janusgraph/issues/2950 Thanks, Peter

Hi Marc, I don't think data cache was created due to elastic search/mixed index only. I have seen this on basic property/node without index as well. I am thinking let's work on basic node/property

Hi Peter, Thanks for reporting. I think it is a bug. I checked with the standalone gremlin REPL of janusgraph-0.6.0, using: graph = JanusGraphFactory.open('conf/janusgraph-inmemory.properties') This

Hi Harshit, The performance impact for JanusGraph when including a property key in multiple mixed indices, is negligable (the selection of the index for a specific query will be a tat slower).

Hi Pawan, OK, let's investigate further. You say that the issue occurs for both vertex creation and modification. Let's take the clearest case first: vertex creation with an indexed property. So, in

Will there be any performance impact if i will index a property key in multiple indices (mixed index)?