Future plans for more sophisticated vertex-centric indexing?

[makoConstruct]

For instance

• Indexes with secondary sort fields*
• Indexes applying to properties of the nodes, rather than the edges pointing at them(important for checking whether known nodes are connected or disconnecting them). For nodes of types A and B on either side of an edge type E, There are four kinds of indexes a user might want to maintain. B accessible from A through incident Es, E accessible from A, A accessible from B through incident Es, and E accessible from B. As far as I can tell, currently you can only index the incident Es.
• Multiple indexes on each node, and support for managing them explicitly. *

* You have these things. I was looking at the wrong docs. Apologies.

[mbroecheler]

In 0.5 we introduced secondary sort fields and support for multiple indexes per label. Am I misunderstanding those feature requests?

[makoConstruct]

Where is that documented? I would have hoped to find it here https://github.com/thinkaurelius/titan/wiki/Vertex-Centric-Indices

[makoConstruct]

Multiple indexes per label.. How? The given example only shows how to tell titandb to index all edges of the given label during the creation of the label. I can imagine the API for secondary sort fields(repeated sortBys?) but I can't guess how you would create indexes on a different set of properties.

[rjbriody]

The docs for 0.5+ have moved:

[image: Inline image 1]

...this warning could probably stand to be a little more noticeable, but
check out the 0.5 docs and see what you think.

http://s3.thinkaurelius.com/docs/titan/0.5.0/indexes.html#vertex-indexes

Bob

On Mon, Feb 2, 2015 at 1:47 AM, mako yass notifications@github.com wrote:

Multiple indexes per label.. How? The given example only shows how to tell
titandb to index all edges of the given label during the creation of the
label. I can imagine the API for secondary sort fields(repeated sortBys?)
but I can't guess how you would create indexes on a different set of
properties.

—
Reply to this email directly or view it on GitHub
#946 (comment).

[makoConstruct]

Ahh.. If there is a doc-usability issue here at all, rather than just random stupidity on my part, I guess it would have helped if the link to the new docs linked straight there. I vaguely remember clicking through, possibly ctrl+f ing "vertex-centric", getting nothing, and going back.

Anyway, so you have secondary sort fields and you explicitly name indices so managing multiple indices applying to the same edge label is straightforward.

But you're still missing Vertex-relative vertex indices. So, to expand on what I mean by that, I'll give an example: Say you wanted to query for all of the monsters Hercules has battled with names starting with a "G". Currently the only way to do this efficiently would be to pull monster names into the schema for Battle edges and do vertex centric edge queries from Hercules over those names.

What I would prefer is maintaining a vertex centric index about hercules, on the vertices incident to hercules through battled edges. The name field would get to stay where it belongs. Less wasted storage space, less error-prone, less annoying, whatever other advantages data normalization offers.

[crakjie]

makoConstruct I like this idee 👍

[sharpau]

I would also like to use this feature. It would definitely help with the common case where currently a vertex property must be duplicated on an edge for performance reasons.