I have an Edgelabel
ContainsAttribute
which has Multiplicity.SIMPLE
These edges also have a property let's call it x
that I want to make the vertex-centric index on.
PropertyKey propertyX = mgmt.getPropertyKey("x");
EdgeLabel containsAttributeLabel = mgmt.makeEdgeLabel(EdgeLabels.ContainsAttribute).multiplicity(Multiplicity.SIMPLE).make();
mgmt.buildEdgeIndex(containsAttributeLabel,"propXIndex",Direction.IN, propertyX);
So the edges represent Entity --containsAttribute --> Attribute
. The query I am trying to make will try to search Entities given queries by filtering on the Property x
.
I wonder why it doesn't allow me saying:
The relation type [ContainsAttribute] has a multiplicity or cardinality constraint in direction [IN] and can therefore not be indexed
I think my use case makes sense and I wouldn't want to relax my edge label multiplicity from SIMPLE
to MANY2ONE
,ONE2MANY
or MULTI
, to make it work.
Edit: According to the example http://s3.thinkaurelius.com/docs/titan/1.0.0/indexes.html Hercules battled a lot of monsters so the edges labeled 'battled' are found coming out of 'Hercules' multiple times connecting with different monsters. Then the edge index is on attribute 'time' so filtering can be done. I want to do something similar and I thought vertex-centric indices are the way.. Those edges are Multiplicity.SIMPLE because there is at most one edge labeled 'battled' between Hercules and each of the monsters.
Edit 2:
Similar to the given example again a SIMPLE graph:
I believe it would make sense to have a vertex-centeric index for Hercules and the out-going SIMPLE 'battled' edges. That would make queries like time >=20
faster when traversing from Hercules to the monsters.
I don't understand why we must have a MULTI graph (less strict) like below to leverage vertex-centric indices..
Any help would be appreciated! Thanks!