[Neo4j] [Blueprints] Index API look and feel (RFC)

Walaa Eldin Moustafa wa.moustafa at gmail.com
Tue Oct 26 19:19:21 CEST 2010

Thank you for this useful information. I understood that Neo4j
implements the Lucene index which supports node indexing only but not
edge indexing. Also, from what I understand from the Blueprints API,
it can support both node and edge indexing, and it also supports Neo4j
as an underlying implementation. Does that mean that by using the
Blueprints API, we can have support for Neo4j edge indexing?


On Tue, Oct 26, 2010 at 12:47 PM, Marko Rodriguez <okrammarko at gmail.com> wrote:
> Hi everyone,
> *** I've included the Neo4j users group in the mailing in case they have any thoughts on the matter. ***
> So these are the classes currently associated with Indexing in the next release of Blueprints [ http://blueprints.tinkerpop.com ]. Much of this was inspired by the multi-indexing framework provided in the latest Neo4j. After a presentation of the Blueprints interfaces, a discussion ensues.
> public interface IndexableGraph extends Graph {
>    public <T> Index<T> acquireIndex(String indexName, Class<T> indexClass);
>    public Iterable<Index> getIndices();
>    public void dropIndex(String indexName);
> }
> public interface Index<T> {
>    public String getIndexName();
>    public Class<T> getIndexClass();
>    public void put(String key, Object value, T object);
>    public Iterable<T> get(String key, Object value);
>    public void remove(String key, Object value, T object);
> }
> public interface AutomaticPropertyIndex<T> extends Index<T> {
>    public void addAutoIndexKey(String key);
>    public void removeAutoIndexKey(String key);
>    public Set<String> getAutoIndexKeys();
> }
> A graph (e.g. Neo4j, OrientDB, TinkerGraph, etc.) can implement IndexableGraph (analogous to TransactionalGraph, but for indices as opposed to transactions). Indices can be created and retrieved (acquireIndex(), getIndices()) and dropped (dropIndex()) through the main graph class. Every index maintains standard get/put/remove methods as well as their String name and the class type that they index. For Neo4j, these are <? extends PropertyContainer> type indices. For OrientDB and TinkerGraph, any Java object (serializable for OrientDB) can be stored in an Index. Finally, to maintain the "user friendly" nature of Blueprints, there is an AutomaticPropertyIndex interface that can be used if so desired. This is like TransactionalGraph.Mode.AUTOMATIC, but for automatically indexing vertices/edges for the user. An AutomaticPropertyIndex will automatically maintain an index of your vertices/edges as you add, remove, update properties on those vertices/edges.
> For those familiar with Blueprints 0.2 and the past single-index model, the only difference is now a graph can have multiple indices. This will incur some minor changes to Gremlin and will be discussed in a later email.
> I've already implemented this for Neo4j and TinkerGraph to get "a feel" for the API and so far its feeling fine. There are a few oddities that need to be thought out (e.g. unique naming for indices, etc.). Thoughts are more than welcome.
> Take care,
> Marko.
> http://markorodriguez.com
> http://gremlin.tinkerpop.com
> _______________________________________________
> Neo4j mailing list
> User at lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user

More information about the User mailing list