Hi,

i created an index with HS 3.2. (core 3.5.) with the massindexer. The application i use the index in, uses HS 3.0.1 (core 3.2.6), and its not possible to change that. Now the index created with 3.2. isnt working with 3.0.1, it throws the exception:



is it possible to generate an index with HS 3.5. and use it with HS 3.0.1 at all?
(i remember that i've seen some constants in a code like "Lucene.Version_XX", but i don't remember where i've seen that)

I don't believe it is possible to down grade, for example building index with a higher version and then trying to read them with a lower version. You can obviously do it the other way around.

thx, but the other way round wouldnt help me at all. the problem is, as told before, the environment i'm searching on, isnt able to upgrade to a newer version of hibernate, so it can't make use of hibernate search 3.2 with its massindexer. So i have to find a way, to use the massindexer building up an index that can be read by hibernate search 3.0.1. Using the old way, with that pagination and all that stuff, drives me nuts, and will cost way to much time.

isnt there a way to convert the (lucene)2.9.2-index to an 2.3-index? luke can handle all of these, so at least there have to be a way to read all of them. Once i read it into memory, i could use an old version of an indexwriter to produce a 2.3-index, couldn't i?

This incompatibility is coming from Lucene index formats. HS 3.2 is targeting Lucene 2.9 but should work also on Lucene 2.4.1, which was the version supported by HS 3.1.
The Lucene version used by HS 3.0.1 is older and it won't work using the same one, but I think that if you use HS3.2 with Lucene 2.4 this could be able to produce an index which is usable by the older Lucene, it's only in 2.9 that internal formats changed radically (it's basically a 3.0 preview, with backwards API compatibility).

that sounds nice, but if i replace the lucene core 2.9.2 with the 2.4.1 in my indexbuilding app, i get the following exception:

ah sorry; so it's not compatible, but it should be simple to convert as I expect just a bunch of method signatures to be changed;

easier than to backport the massindexer anyway.

ok, now i've created twice time an index of the same db, one time with HS 3.5 (lucene 2.9.2), the other one with HS 3.1. (lucene 2.4.1). When i open one of the directorys a class is stored in, the structure is completly different. One has 25 objects (the 2.4.1. one), the other one just has 3 objects (the 2.9.2 one), obv. the second one stores all of the information in one file, while the other one distributes it to different files. another problem is that the content is binary (ok, not really binary, but a lot of control characters), i don't see any chance here, how i should be able to convert that. Any ideas?

Lucene creates several segments, and periodically merges them back in one to optimize search performance. Make sure to call "optimize()" to force merging to a single main file + some metadata . The Massindexer by default optimizes at the end, so that's likely already done with 3.2.

To inspect the index, use Luke. And no, I see no way to convert it manually, as you've seen the format is complex and really meant for maximum performance.

Are you able to load the index produced by HS3.1 by HS3.0.1 ?

I don't think i'll get this working the way i wanted to. Switched back to 3.0.1 and try&errror finetuning my parameters with the scrolledResultSet. With current settings i will need approx. 8h instead of 40 minutes. Sick, but obv. there is no other way?!?

really, adapting the code of HS 3.2 to use Lucene 2.4 is easy, something around 3 lines of code.

It's harder to adapt it to Lucene 2.3, so I'd check if you're able to read the index produced by HS3.1+Lucene2.4 by your older app, if that works I can help you in doing the trivial changes, so you can have a HS3.2-Custom+Lucene2.4 to produce the index for your HS3.0.1+Lucene2.3

Well, would really be nice to have that, i just do not have the time this week to check it. maybe next week. thx for your replies anyway.