Yay! We're on a role here.
However, I suspect that deprecating the index.add(node,string,object) will
not be easy. The usage of that is somewhat different, and probably
widespread. I think both styles will need to co-exist. The trick is to get
them to co-exist without creating confusion.
On Sun,
Yes,
"Upfront configured indexes" IMHO are very useful, especially if we
connect them with events later ... they probably fit a wide array of
use cases.
Cheers,
/peter neubauer
GTalk: neubauer.peter
Skype peter.neubauer
Phone +46 704 106975
LinkedIn http://www.linkedin.com/in/
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 index = db.index().forNodes(Map
Excellent - a truce :-)
So, let's get something in place this week. We both want to see the spatial
index (and I hope the composite index) get some more visibility, and we both
want it to be as clear an intuitive as possible.
On Sun, Nov 28, 2010 at 6:10 PM, Peter Neubauer <
peter.neuba...@neotec
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 106
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(nod
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 co
>
> 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 li
I must admit I am not happy with the index.add(node,key,value) API for
spatial data. See the line in Peters code:
index.add( n1, "dummy", "value" );
Peter had to put dummy values in the call to 'work around' this requirement.
In fact I'm not happy with this for my composite index either. For both
On Fri, Nov 26, 2010 at 10:54, Peter Neubauer
wrote:
> [...] This syntax
> might make it easier to expose things in Ruby, REST and others, too.
> WDYT?
>
> For the heavy query lifting and GIS stack integration, the GeoTools
> API is the way to go though ...
Any mechanism that make possible to bui
Thanks for the feedback!
On the GoeSpatial side, I am trying to get the setup easier, so for
"normal" stuff, you don't have to go through GeoTeools but can use the
Neo4j Index setup, see
https://github.com/neo4j/neo4j-spatial/blob/300f4d1d1fbb92d6252d5be6dc334250c9514bc7/src/test/java/org/neo4j/gi
On Fri, Nov 26, 2010 at 02:03, Peter Neubauer <
peter.neuba...@neotechnology.com> wrote:
> Btw, what does everyone feel about REST vs. native protocols like RMI,
> Protobuffers, etc that can support a full Neo4j remote API for
> integration, with TX etc and would be optimized for driver developmen
2010 2:04 AM
To: neo4jrb; Neo4j user discussions
Subject: Re: [Neo4j] Release 1.0.0.beta.22
Great stuff Andreas,
we had a great evening in Barcelona yesterday, showing off the great
work you, Ben and all the others are doing! Fantastic API and
features!
Craig and me are working on getting the Neo4
Great stuff Andreas,
we had a great evening in Barcelona yesterday, showing off the great
work you, Ben and all the others are doing! Fantastic API and
features!
Craig and me are working on getting the Neo4j Spatial supported (at
least the basic features) as a normal index provider in Neo4j. That
14 matches
Mail list logo
