Great... Looking forward to your contributions. Once the port is done, we can look at making improvements.
> From: [email protected] > Date: Wed, 29 Jun 2011 16:34:39 -0700 > To: [email protected] > Subject: Re: [Neo4j] neo4j-graph-collections > > I'm definitely interested and will contact you soon to follow up. > > Sent from my iPhone > > On Jun 29, 2011, at 4:17 PM, Craig Taverner <[email protected]> wrote: > > > I think moving the RTree to the generic collections would not be too hard. I > > saw Saikat showed interested in doing this himself. > > > > Saikat, contact me off-list for further details on what I think could be > > done to make this port. > > > > On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen > > <[email protected]>wrote: > > > >> > >> Peter, I totally agree. Having the Rtree index removed of spatial > >> dependencies in graph-collections should be our first priority. Once that > >> is > >> done we can focus on the other issues. > >> Which doesn't mean we should stop discussing future improvements like > >> setting up comparators (or something to that extent) that can be reusable, > >> but we shouldn't try to get that up before Rtree is in graph-collections. > >> Niels > >> > >>> From: [email protected] > >>> Date: Wed, 29 Jun 2011 21:10:15 +0200 > >>> To: [email protected] > >>> Subject: Re: [Neo4j] neo4j-graph-collections > >>> > >>> Craig, > >>> just gave you push access to the graph collections in case you want to > >>> do anything there. > >>> > >>> Also, IMHO it would be more important to isolate and split out the > >>> RTree component from Spatial than to optimize it - that could be done > >>> in the new place with targeted performance tests later? > >>> > >>> 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 Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen > >>> <[email protected]> wrote: > >>>> > >>>> Craig, > >>>> Would it be possible to merge your work on Amanzi with the work the Neo > >> team has done on the Btree component that is now in > >> neo4j-graph-collections, > >> so we can eventually have one implementation that meets a broad variety of > >> needs? > >>>> Niels > >>>> > >>>>> Date: Wed, 29 Jun 2011 15:34:47 +0200 > >>>>> From: [email protected] > >>>>> To: [email protected] > >>>>> Subject: Re: [Neo4j] neo4j-graph-collections > >>>>> > >>>>> I have previously used two solutions to deal with multiple types in > >> btrees: > >>>>> > >>>>> - My first index in 2009 was a btree-like n-dim index using > >> generics to > >>>>> support int[], long[], float[] and double[] (no strings). I used > >> this for > >>>>> TimeLine (long[1]) and Location (double[2]). The knowledge about > >> what type > >>>>> was used was in the code for constructing the index (whether a new > >> index or > >>>>> accessing an existing index in the graph). > >>>>> - In December I started my amanzi-index (on > >>>>> github<https://github.com/craigtaverner/amanzi-index>) > >>>>> that is also btree-like, n-dimensional. But this time it can index > >> multiple > >>>>> types in the same tree (so a float, int and string in the same > >> tree, instead > >>>>> of being forced to have all properties of the same type). It is a > >> re-write > >>>>> of the previous index to support Strings, and mixed types. This > >> time it does > >>>>> save the type information in meta-data at the tree root. > >>>>> > >>>>> The idea of using a 'comparator' class for the types is similar, but > >> simpler > >>>>> than the idea I implemented for amanzi-index, where I have mapper > >> classes > >>>>> that describe not only how to compare types, but also how to map from > >> values > >>>>> to index keys and back. This includes (to some extent) the concept of > >> the > >>>>> lucene analyser, since the mapper can decide on custom distribution > >> of, for > >>>>> example, strings and category indexes. > >>>>> > >>>>> For both of these indexes, you configure the index up front, and then > >> only > >>>>> call index.add(node) to index a node. This will fit in well with the > >> new > >>>>> auto-indexing ideas in neo4j. > >>>>> > >>>>> On Wed, Jun 29, 2011 at 2:25 PM, Niels Hoogeveen > >>>>> <[email protected]>wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> At this moment Btree only supports the primitive datatype long, > >> while Rtree > >>>>>> only supports the datatype double. For Btree it makes sense to at > >> least > >>>>>> support strings, floats, doubles and ints too. Use cases for these > >> data > >>>>>> types are pretty obvious and are Btree backed in (almost) every > >> RDBMS > >>>>>> product around.I think the best solution would be to create > >> Comparator > >>>>>> objects wrapping these primitive data types and store the class name > >> of the > >>>>>> comparator in root of the index tree. This allows users to create > >> their own > >>>>>> comparators for datatypes not covered yet. It would make sense > >> people would > >>>>>> want to store BigInt and BigDecimal objects in a Btree too, others > >> may want > >>>>>> to store dates (instead of datetime), fractions, complex numbers or > >> even > >>>>>> more exotic data types. > >>>>>> Niels > >>>>>>> From: [email protected] > >>>>>>> To: [email protected] > >>>>>>> Date: Tue, 28 Jun 2011 22:43:24 -0700 > >>>>>>> Subject: Re: [Neo4j] neo4j-graph-collections > >>>>>>> > >>>>>>> > >>>>>>> I've read through this thread in more detail and have a few > >> thoughts, > >>>>>> when you talk about type I am assuming that you are referring to an > >>>>>> interface that both (Btree,Rtree) can implement, for the data types > >> I'd like > >>>>>> to understand the use cases first before implementing the different > >> data > >>>>>> types, maybe we could store types of Object instead of Long or > >> Double and > >>>>>> implement comparators in a more meaningful fashion. Also I was > >> wondering > >>>>>> if unit tests would need to be extracted out of the spatial > >> component and > >>>>>> embedded inside the graph-collections component as well or whether > >> we'd > >>>>>> potentially need to write brand new unit tests as well. > >>>>>>> Craig as I mentioned I'd love to help, let me know if it would be > >>>>>> possible to fork a repo or to talk in more detail this week. > >>>>>>> Regards > >>>>>>> > >>>>>>>> From: [email protected] > >>>>>>>> To: [email protected] > >>>>>>>> Date: Wed, 29 Jun 2011 01:35:43 +0200 > >>>>>>>> Subject: Re: [Neo4j] neo4j-graph-collections > >>>>>>>> > >>>>>>>> > >>>>>>>> As to the issue of n-dim doubles, it would be interesting to > >> consider > >>>>>> creating a set of classes of type Orderable (supporting <, <=, >, >= > >>>>>> operations), this we can use in both Rtree and Btree. Right now > >> Btree only > >>>>>> supports datatype Long. This should also become more generic. A > >> first step > >>>>>> we can take is at least wrap the common datatypes in Orderable > >> classes. > >>>>>>>> Niels > >>>>>>>> > >>>>>>>>> Date: Wed, 29 Jun 2011 00:32:15 +0200 > >>>>>>>>> From: [email protected] > >>>>>>>>> To: [email protected] > >>>>>>>>> Subject: Re: [Neo4j] neo4j-graph-collections > >>>>>>>>> > >>>>>>>>> The RTree in principle should be generalizable, but the > >> current > >>>>>>>>> implementation in neo4j-spatial does make a few assumptions > >> specific > >>>>>> to > >>>>>>>>> spatial data, and makes use of spatial envelopes for the tree > >> node > >>>>>> bounding > >>>>>>>>> boxes. It is also specific to 2D. We could make a few > >> improvements > >>>>>> first, > >>>>>>>>> like generalizing to n-dimensions, replacing the recursive > >> search > >>>>>> with a > >>>>>>>>> traverser and generalizing the bounding boxes to be simple > >>>>>> double-arrays. > >>>>>>>>> Then the only thing left would be to decide if it is ok for it > >> to be > >>>>>> based > >>>>>>>>> on n-dim doubles or should be generalized to more types. > >>>>>>>>> > >>>>>>>>> On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal < > >>>>>> [email protected]>wrote: > >>>>>>>>> > >>>>>>>>>> I would be interested in helping out with this, let me know > >> next > >>>>>> steps. > >>>>>>>>>> > >>>>>>>>>> Sent from my iPhone > >>>>>>>>>> > >>>>>>>>>> On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen < > >>>>>> [email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> A couple of weeks ago Peter Neubauer set up a repository > >> for > >>>>>> in-graph > >>>>>>>>>> datastructures: > >> https://github.com/peterneubauer/graph-collections > >>>>>> . > >>>>>>>>>>> At this time of writing only the Btree/Timeline index is > >> part of > >>>>>> this > >>>>>>>>>> "component". > >>>>>>>>>>> In my opinion it would be interesting to move the Rtree > >> parts of > >>>>>>>>>> neo-spatial to neo4j-graph-collections too. > >>>>>>>>>>> I looked at the code but don't feel competent to seperate > >> out > >>>>>> those > >>>>>>>>>> classes that support generic Rtrees from those classes that > >> are > >>>>>> clearly > >>>>>>>>>> spatial related. > >>>>>>>>>>> Is there any enthusiasm for such a project and if so, who > >> is > >>>>>> willing and > >>>>>>>>>> able to do this? > >>>>>>>>>>> Niels > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Neo4j mailing list > >>>>>>>>>>> [email protected] > >>>>>>>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> Neo4j mailing list > >>>>>>>>>> [email protected] > >>>>>>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Neo4j mailing list > >>>>>>>>> [email protected] > >>>>>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Neo4j mailing list > >>>>>>>> [email protected] > >>>>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Neo4j mailing list > >>>>>>> [email protected] > >>>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Neo4j mailing list > >>>>>> [email protected] > >>>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>>>> > >>>>> _______________________________________________ > >>>>> Neo4j mailing list > >>>>> [email protected] > >>>>> https://lists.neo4j.org/mailman/listinfo/user > >>>> > >>>> _______________________________________________ > >>>> Neo4j mailing list > >>>> [email protected] > >>>> https://lists.neo4j.org/mailman/listinfo/user > >>>> > >>> _______________________________________________ > >>> Neo4j mailing list > >>> [email protected] > >>> https://lists.neo4j.org/mailman/listinfo/user > >> > >> _______________________________________________ > >> Neo4j mailing list > >> [email protected] > >> https://lists.neo4j.org/mailman/listinfo/user > >> > > _______________________________________________ > > Neo4j mailing list > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
