I'm afraid it's too late to switch to a new version of lucene now for 1.4,
but I can see it entering early 1.5 if there's no show stopper.
Compilation-and-unit-tests-wise Lucene 3.2 seems to just work when replacing
it with 3.1 in 1.4-SNAPSHOT, that's all I know about it at this stage. I
also don't know if there's any chance of downgrading a 3.2 index to 3.1.

I think it's fair to say that using neo4j 1.4 it's probably a small time
investment to upgrade to Lucene 3.2 yourself and try it out, perhaps nothing
more than that is required. Although new features, like the new
NRTCachingDirectory, may not be used. Things shouldn't break down hard
anyway.

Interesting changeset b.t.w.

2011/6/20 Rick Bullotta <[email protected]>

> Any chance of testing/releasing Neo4J 1.4 with Lucene 3.2.0?  Some good
> stuff in there that would help Neo users, notably the upgrader, grouping,
> performance improvements and the Numeric field fix.
>
> *         A new grouping module, under lucene/contrib/grouping, enables
> search results to be grouped by a single-valued indexed field
> *         A new IndexUpgrader tool fully converts an old index to the
> current format.
> *         A new Directory implementation, NRTCachingDirectory, caches small
> segments in RAM, to reduce the I/O load for applications with fast NRT
> reopen rates.
> *         A new Collector implementation, CachingCollector, is able to
> gather search hits (document IDs and optionally also scores) and then replay
> them. This is useful for Collectors that require two or more passes to
> produce results.
> *         Index a document block using IndexWriter's new addDocuments or
> updateDocuments methods. These experimental APIs ensure that the block of
> documents will forever remain contiguous in the index, enabling interesting
> future features like grouping and joins.
> *         A new default merge policy, TieredMergePolicy, which is more
> efficient due to being able to merge non-contiguous segments. Seehttp://
> s.apache.org/merging for details.
> *         NumericField is now returned correctly when you load a stored
> document (previously you received a normal Field back, with the numeric
> value converted string).
> *         Deleted terms are now applied during flushing to the newly
> flushed segment, which is more efficient than having to later initialize a
> reader for that segment.
>
> _______________________________________________
> Neo4j mailing list
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
>



-- 
Mattias Persson, [[email protected]]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to