2011/6/3 Rick Bullotta <rick.bullo...@thingworx.com> > Alternatively, if we could have the "composite index" functionality I > described in a few previous e-mails (mix timestamp, textual and other > numeric key/values in the same index) - e.g. a Lucene timeline index with > extra keys, that might work well also, would it not? >
That is possible using a lucene index as it is today afaik. Just get inspiration from LuceneTimeline for the timestamp parts and fire away! > > -----Original Message----- > From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] > On Behalf Of Niels Hoogeveen > Sent: Friday, June 03, 2011 2:44 PM > To: user@lists.neo4j.org > Subject: [Neo4j] In-graph Timeline index and Neo4j 1.4 > > > Today, I tried to migrate my application from Neo4j 1.3 to 1.4M03 and ran > into problems with respect to the in-graph Timeline index in the legacy > component Neo4j-index. > For all Lucene related indexing, I have moved to greener pastures and use > the new indexing framework, but for several indexing needs only an in-graph > index is suitable. > Examples:1) Most of the nodes in my application have versioning enabled. To > do so, I maintain a in-graph Timeline index containing "version nodes". The > Timeline index is needed to maintain order and to register a timestamp for > each version. > 2) Most of the nodes in my application are related to a context. Every user > or user group maintains two or more contexts. The relationship between node > and context is again stored in the Timeline index, to make it possible to > retrieve the most recent additions for a user or user group. > Both scenarios can potentially create a huge number of indexes, most of > them relatively small, but some become large enough that in-memory sorting > is not an option. > The in-graph Timeline index offers the right functionality for these > scenarios and the Lucene index service is not a feasible replacement in > these cases. > The in-graph Timeline index is now fixed to version Neo4j 1.3, and given > the legacy Lucene code in that component will not likely be upgraded to > version 1.4. > Using Neo4j-index 1.3-SNAPSHOT with Neo4j 1.4M03 is not possible without > hacking the POM (which I have done, but don't feel too happy about). > Neo4j-index 1.3-SNAPSHOT requires Lucene 3.0.1, while Neo4j 1.4M03 requires > Lucene 3.1.0, leading to version conflicts in projects. > Approximately a month ago, I made the suggestion (see: > http://lists.neo4j.org/pipermail/user/2011-May/008461.html) to move the > in-graph Btree index and its related classes (including Timeline) to a new > component Neo4j-collections, while keeping the old Lucene index stuff in > Neo4j-index, so it can eventually become deprecated. > I hope my suggestion will be taken into consideration. > Kind regards,Niels Hoogeveen > > > _______________________________________________ > 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
