Yes, actually it's not that bad of an idea :) You control which properties
are going to be indexed with a configuration parameter up front and then you
just hand the PropertyContainer to the index and it'll index those
properties it was told to index, like:
Index<Node> index = db.index().forNodes(MapUtil.stringMap(
"provider", "lucene", "type", "exact", "keys_to_index", "name,title"
) );
...
index.add( node );
index.add( anotherNode );
You could still keep the add(entity,key,value) maybe for special cases? Or
maybe that'd be confusing.
2010/11/28 Peter Neubauer <peter.neuba...@neotechnology.com>
> Yes,
> totally true. We should talkt ot Mattias on the option of having some
> Index suppoerted that is configured upfront and then simply has
> index.add(PropertyContainer). Totally with you there :)
>
> 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 Sun, Nov 28, 2010 at 6:08 PM, Craig Taverner <cr...@amanzi.com> wrote:
> > 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
> >
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
--
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
