Done!
----- Reply message ----- From: "Mattias Persson" <[email protected]> Date: Wed, Jun 15, 2011 7:14 am Subject: [Neo4j] In-graph Timeline index and Neo4j 1.4 To: "Neo4j user discussions" <[email protected]> 2011/6/3 Rick Bullotta <[email protected]> > 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: [email protected] [mailto:[email protected]] > On Behalf Of Niels Hoogeveen > Sent: Friday, June 03, 2011 2:44 PM > To: [email protected] > 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 > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [[email protected]] Hacker, Neo Technology www.neotechnology.com<http://www.neotechnology.com> _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
