Sorry I am not sure about that… Maybe Jan (CCed) could answer that?

Hello Boxuan, Does it mean there is no existing release version for full install with this issue being fixed? Would it be possible to have a release with the fix as the code seems available? The

Hi Yingjie, You might need to backport https://github.com/JanusGraph/janusgraph/pull/2890 to 0.6 branch and build your own JanusGraph. You are also welcome to use the master branch to build

Just wondering if anybody has a fix for this? The security issue is a roadblock for us to continue using Janusgraph in our project. Thanks

Hi Marc - as usual you are on the right path. The number of edges on the nodes in question was very high, so doing any sort of query on it is slow. The query was timing out; not sure what

hi @hadoopmarc So the problem is : "gremlin> g.V().has("newid","xyz").valueMap(true).tryNext().isPresent()"however it gives false. - This one would have given true response . Also it does use index

H Nikita, Two questions: Do I understand right that g.V().has("newid", "xyz").count().profile() gives and index warning while g.V().has("newid","xyz").valueMap(true).tryNext().isPresent() does not

Hi Joe, I have no detailed knowledge of the JanusGraph backend code myself, but just a reaction for clarification (so that others see more hints to the cause of the issue): Is it possible that the

gremlin> g.V().has("newid","xyz").valueMap(true).tryNext().isPresent() ==>false gremlin> g.V().has("newid",unfold().is("hash data")).valueMap(true).tryNext().isPresent() 07:01:35 WARN

g.V().has("newid", "xyz").count().profile() 04:31:35 WARN org.janusgraph.graphdb.transaction.StandardJanusGraphTx - Query requires iterating over all vertices [(newid xyz)]. Even though the newid

Hi all - I'm getting the following error when executing the following query: List<Object> correlationIDsListSource = traversal.V().has("source", source).outE("correlation").has("type",

> I've seen cases in the past, where queries relying on a mixed index fail while the index backend still hasn't caught up to the storage backend. Yes that could happen. You can use

That's a great post. This is exactly the use-case we have, with a type property. Regarding the usage of mixed indexes - - I'm less concerned with property updates in this case (as opposed to

Hi Assaf, I see. That makes sense and unfortunately, I don't have a perfect solution. I would suggest you use a mixed index instead. Regarding the data model, you can take a look at a blog I wrote

Hi Boxuan - thanks for the quick response! I get a feeling that 2) might be the issue. Since JanusGraph has never allowed us to index labels, we ended up having a "shadow property" which is set as a

Hi Assaf, Having too many vertices with the same label shouldn't be a problem. The two most possible causes are: 1) You have a super node that has too many edges. 2) You have a composite index with

Hi! We are using JG on top of Bigtable. While trying to understand some slow queries, I found the following in the Bigtable query vizualizer: "Large rows — Found 1 single key storing more than

Hello Marc, Actually my previous testing was incomplete. After removing those two log4j related jar files from the lib directory, I can start elasticsearch, cassandra and Janusgraph server

Apparently it replaces the full path to the properties file with a relative path (conf/remote-graph.properties), which isn't found, of course. So, I've copied them and now I can connect. Thanks.

The stacktrace is not very helpful, unfortunately, but that is not your doing. The original example does not use an "ats" variable but instantiates g with a oneliner, but it hard to see why this could