Craig, the autoindexing is one step in this direction. The other is to enable the Spatial and other in-graph indexes like the graph-collections (timeline etc) at all to be treated like normal index providers. When that is done (will talk to Mattias who is coming back from vacation tomorrow on that), we are in a position to think about more complex autoindex providers.
Also, the possibility to treat Neo4j Spatial and other graph structures as index providers, would hook into the index framework and expose things to higher level queries like Cypher and Gremlin, e.g. combining a spatial bounding box geometry search with a graph traversal for suitable properties that are less than 2 kilometers from the nearest school, sorting the results, returning only price and lat as columns, the 3 topmost hits. START geom = (index:spatial:'BBOX(the_geom, -90, 40, -60, 45)') MATCH (geom)-->(fast), (fast)-[r, :NEAR]-(school) WHERE fast.roooms>4 AND school.classes>4 AND r.length<2return fast.pic?, fast.lon?, fast.lat? SORT BY fast.price, fast.lat^ SLICE 3 So, I think the next step is to make in-graph indexing structures plug into the index framework, and then into autoindexing :) Cheers, /peter neubauer GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://startupbootcamp.org/ - Öresund - Innovation happens HERE. http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. On Tue, Jun 14, 2011 at 5:49 PM, Craig Taverner <cr...@amanzi.com> wrote: > This is great news. > > Now I'm really curious about the next step, and that is allowing indexes > other than lucene. For example, the RTree index in neo4j-spatial was never > possible to wrap behind the normal index API, because that was designed only > for properties of nodes (and relationships), but the RTree is based on > something completely different (complete spatial geometries). However, the > new auto-indexing feature implies that any node can be added to an index > without the developer needing to know anything about the index API. Instead > the index needs to know if the node is appropriate for indexing. This is > suitable for both lucene and the RTree. > > So what I'd like to see is that when configuring auto-indexing in the first > place, instead of just specifying properties to index, specify some indexer > implementation that can be created and run internally. For example, perhaps > you pass the classname of some class that implements some necessary > interface, and then that is instantiated, passed config properties, and used > to index new or modified nodes. One method I could imagine this interface > having would be a listener for change events to be evaluated for whether or > not the index should be activated for a node change. For the lucene property > index, this method would return true if the property exists on that node. > For the RTree this method would return true if the node contained the > meta-data required for neo4j-spatial to recognize it as a spatial type? > Alternatively just an index method that does nothing when the nodes are not > to be indexed, and indexes when necessary? > > So, are we now closer to having this kind of support? > > On Tue, Jun 14, 2011 at 11:30 PM, Chris Gioran < > chris.gio...@neotechnology.com> wrote: > >> Good news everyone, >> >> A request that's often come up on the mailing list is a mechanism for >> automatically indexing properties of nodes and relationships. >> >> As of today's SNAPSHOT, auto-indexing is part of Neo4j which means nodes >> and relationships can now be indexed based on convention, requiring >> far less effort and code from the developer's point of view. >> >> Getting hold of an automatic index is straightforward: >> >> AutoIndexer<Node> nodeAutoIndexer = graphDb.index().getNodeAutoIndexer(); >> AutoIndex<Node> nodeAutoIndex = nodeAutoIndexer.getAutoIndex(); >> >> Once you've got an instance of AutoIndex, you can use it as a read-only >> Index<Node>. >> >> The AutoIndexer interface also supports runtime changes and >> enabling/disabling the auto indexing functionality. >> >> To support the new features, there are new Config >> options you can pass to the startup configuration map in >> EmbeddedGraphDatabase, the most important of which are: >> >> Config.NODE_AUTO_INDEXING (defaults to "false") >> Config.RELATIONSHIP_AUTO_INDEXING (defaults to "false") >> >> If set to "true" (independently of each other) these properties will >> enable auto indexing functionality and at the successful finish() of >> each transaction, all newly added properties on the primitives for which >> auto indexing is enabled will be added to a special AutoIndex (and >> deleted or changed properties will be updated accordingly too). >> >> There are options for fine grained control to determine >> properties are indexed, default behaviors and so forth. For example, by >> default all properties are indexed. If you want only properties "name" and >> "age" for Nodes and "since" and "until" for Relationships >> to be auto indexed, simply set the initial configuration as follows: >> >> Config.NODE_KEYS_INDEXABLE = "name, age"; >> Config.RELATIONSHIP_KEYS_INDEXABLE="since, until"; >> >> For the semantics of the auto-indexing operations, constraints and more >> detailed examples, see the documentation available at >> >> http://docs.neo4j.org/chunked/1.4-SNAPSHOT/auto-indexing.html >> >> We're pretty excited about this feature since we think it'll make your >> lives >> as developers much more productive in a range of use-cases. If you're >> comfortable with using SNAPSHOT versions of Neo4j, please try it out >> and let us know what you think - we'd really value your feedback. >> >> If you're happier with using packaged milestones then this feature >> will be available from 1.4 M05 in a couple of weeks from now. >> _______________________________________________ >> Neo4j mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user >> > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
