It seems we are still talking about different things. My request for an index API is actually *simpler* than the existing standard in Neo4j. In fact the existing API is already fine for creating the index, finding the index, performing queries on the index, everything except one call, index.add(node,string,object). I would prefer index.add(node).
So, in terms of API, if we want to discuss simplicity, it is the other way round. However, that is not the issue here. The main argument is all about the *purpose of the index*. The existing API is explicitly for indexing key/value pairs on PropertyContainers. While we could easily adapt this to indexing other concepts, I have strong reservations about whether that is a *good thing(tm)* to do. IMHO it might be somewhat confusing to the user for the same API to be used for different concepts. So, what are our options here? Take a look back at the method I mentioned above: index.add(node,string,object). This call exposes the fundamental difference, and that is that in the current implementation the name of the index really defines a unique implementation of something that can index key-value pairs, and then the key/value to index is specified on each and every add() call. This allows the same index to be used for different properties (keys) in a clean way. If we want to index more complex concepts, like geometry, or multiple linked properties, we could not, and should not, just add new versions of this call for those cases (like add(node,Geometry), or add(node,key1,obj1,key2,obj2,key3,obj3)). IMHO, more complex cases should be handled with a simpler API. Use index.add(node), and make the index instance specific to the particular complication being dealt with. The current API for creating, finding and querying can already handle all levels of complexity. It is only the add() method that is specific to single key-value pairs. This means we have two main options: - Produce an extension/modification to the existing API allowing for index.add(propertyContainer) and keep the current index creation/finding/querying API as is. This would work and the two methods add(node,string,object) and add(node) would be the hint to the user that these are two different types of index. I'm still uncomfortable with this, because I think the difference is too subtle, and likely to lead to confusion. - Have a second index API focusing on the add(node) use case. The second API should be clearly different in intention from the first, because in this case the properties to index are specified at index creation, not when adding to the index. This is a very key difference which I think should be visible to the developer, so they do not mix the two up. And this gets us back to the original point. You must have some reason for wanting to put other, non-key-value, indexes behind the existing key-value index API. As you can tell, so far I can only see problems with this idea, but I'm quite sure you can see advantages with it. Obviously these advantages need to be taken into account. In my opinion the goal should be to achieve maximum overall simplicity and clarity in using indexes of all types in Neo4j. On Sat, Nov 27, 2010 at 11:24 PM, Peter Neubauer < peter.neuba...@neotechnology.com> wrote: > Mmh, > as stated before, IMHO there can be different scenarios of usage of > complex indexes. Of course there is a reason for GeoTools and GIS > systems to have a more complicated API than a Lucene Text search > index. GIS queries tend to be far more complex than text queries, > especially when we want to combine them with other deep raversals > through the graph. In that I agree with you Craig. > > However, I think there is a place for a simple API (with only simple > support for features) that would satisfy a lot of users that are > starting to explore the concept of multidimensional indexing and > simple spatial capabilities, e.g. the stuff that MongoDB and CouchDB > are exposing. It is just a tiny subset of what Neo4j Spatial can do, > but a very approachable start for a lot of users. > > Let's see what we can do in putting Neo4j Spatials both behind > powerful stacks like GeoTools, uDig and GeoServer (and of course a > native traversal API), and expose some limited API through some "easy" > approaches. I am not sure it will work out, it is only experimental at > the moment, but well - this is open source, so let's experiment :) > > 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://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party. > > > > On Fri, Nov 26, 2010 at 8:08 PM, Craig Taverner <cr...@amanzi.com> wrote: > >> > >> Any mechanism that make possible to build traversals with geospatial > >> information through the REST API would be great. > >> So, in some moment in the future, will be possible do traversals with > >> geodata?, I mean, build traversals in which I could asking the nodes > >> using geospatial operations like near, is a point of, overlap with, to > >> a distance less than, etc. > >> > > > > I think it should be relatively easy to add spatial extensions to the > REST > > server, but I've not been involved in the REST project much, so I'd need > to > > discuss this with others. Since the current REST API is based on JSON, > the > > preferred choice for the geometries would be GeoJSON, and I think it > would > > be nice to embed the GeoJSON objects directly in the REST JSON response > > itself. Alternatively your idea of WKT embedded in a JSON value might > work > > well too. We might need some clever tricks to deal with paging large > result > > sets, but I guess that is an issue for all database queries. > > > > Deployment wise I think it would be great if simply adding the > neo4j-spatial > > jar to the Neo4j Server deployment would activate a few spatial queries > that > > could be used. I do not really agree with Peter that spatial can be > slipped > > behind existing API's. I think many, or most things, will require > specific > > spatial queries and spatial responses. I certainly believe this is true > of > > your suggested queries above: near, point of, overlaps with, etc. > > > > Cheers, Craig > > _______________________________________________ > > 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
