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: sxk1...@hotmail.com
> To: user@lists.neo4j.org
> 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: pd_aficion...@hotmail.com
> > To: user@lists.neo4j.org
> > 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: cr...@amanzi.com
> > > To: user@lists.neo4j.org
> > > 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
> > > <sxk1...@hotmail.com>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 <pd_aficion...@hotmail.com>
> > > > 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
> > > > > 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
>
> _______________________________________________
> 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
