9:43 p.m.
Hi,
I upgraded our framework to 5.5.0 and I have a few questions about it.
==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.
Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.
Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?
==
Second, I have warnings like that in my logs:
HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
configured for entity type
fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
an uninverting reader must be created. You should declare the missing sort
fields using @SortField.
Shouldn't it be @Sort*able*Field?
==
And finally, since recently, it's necessary to sort dates using
SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
information in the blog posts of any releases. Or did I miss something?
--
Guillaume
9:34 a.m.
Thanks Guillaume,
Good feedback, see inline.
On 17 Sep 2015, at 21:43, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
Hi,
I upgraded our framework to 5.5.0 and I have a few questions about it.
==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.
Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.
Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?
I will add a FAQ on that, check out this comment and my reply
http://in.relation.to/2015/09/14/sorting-in-hibernate-search-55/#comment-...
<http://in.relation.to/2015/09/14/sorting-in-hibernate-search-55/#comment-...
Basically, you *could* use “IndexUpgrader” but that would not be enough most likely.
Safest best is to reindex.
==
Second, I have warnings like that in my logs:
HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
configured for entity type
fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
an uninverting reader must be created. You should declare the missing sort
fields using @SortField.
Shouldn't it be @Sort*able*Field?
We updated the name recently, I’ll fix that.
==
And finally, since recently, it's necessary to sort dates using
SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
information in the blog posts of any releases. Or did I miss something?
It’s a bit subtle, but yes in the migration guides, you will see that dates now use
numeric fields instead of string (faster and more compact AFAIR). I’ll look at the
migration guide and adjust the wording if I can.
10:11 a.m.
On Thu, Sep 17, 2015 at 8:43 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
Hi,
I upgraded our framework to 5.5.0 and I have a few questions about it.
==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.
Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.
Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?
It should be possible to read Lucene 4 indexes from Lucene 5, but you need
to add the codec in your classpath [1]
Could you give a try and let us know if it works for you?
[1]
http://repo1.maven.org/maven2/org/apache/lucene/lucene-backward-codecs/5....
Cheers,
Gustavo
11:29 p.m.
On 19 September 2015 at 09:11, Gustavo Fernandes <gustavo(a)infinispan.org> wrote:
On Thu, Sep 17, 2015 at 8:43 PM, Guillaume Smet
<guillaume.smet(a)gmail.com>
wrote:
> Hi,
>
> I upgraded our framework to 5.5.0 and I have a few questions about it.
>
> ==
> First, I had to remove the existing indexes otherwise I had exceptions
> about version of the index. Is this expected? As far as I remember, it's
> been a long time since we had to remove the indexes after an upgrade.
>
> Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
> version is not supported (resource
>
>
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
> -11 (needs to be between 1071082519 and 1071082519). This version of
> Lucene only supports indexes created with release 4.0 and later.
>
> Maybe it should be integrated in the blog post that one might need to
> clean up indexes if they come from before the switch to Lucene 4?
>
>
It should be possible to read Lucene 4 indexes from Lucene 5, but you need
to add the codec in your classpath [1]
I did add it to our Maven dependencies but since I marked it
"optional" I guess it was a bit pointless.
https://github.com/hibernate/hibernate-search/blob/master/pom.xml#L210
But: AFAIR pre-4 support was entirely dropped, this additional
dependency is only useful for indexes created between 4.0 to 5.0. You
never fully rebuilt the indexes since Lucene 3.x?
Sorry for not mentioning this in the migration guide, I forgot but
also I do generally assume that people will need to reindex anyway for
various other reasons.
It's mentioned in the Lucene migration guides though, I'm afraid
you'll need to read both ours and Lucene's; the Lucene team recommends
to use the index updater tool in steps: you should be able to upgrade
a Lucene 3 index to a 4 format using the tool at version 4, then with
Lucene 5 move to the format of 5. There might be other benefits of
upgrading formats.
FTR, I did add the lucene-backward-codecs dependency to he modules
included in Wildfly.
Sanne
Could you give a try and let us know if it works for you?
[1]
http://repo1.maven.org/maven2/org/apache/lucene/lucene-backward-codecs/5....
Cheers,
Gustavo
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:31 p.m.
Hi Sanne,
On Sat, Sep 19, 2015 at 11:29 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
But: AFAIR pre-4 support was entirely dropped, this additional
dependency is only useful for indexes created between 4.0 to 5.0. You
never fully rebuilt the indexes since Lucene 3.x?
Probably not - we haven't changed the indexation rules for a while. Lucene
4 support was not added that long ago in Search IIRC.
Sorry for not mentioning this in the migration guide, I forgot but
also I do generally assume that people will need to reindex anyway for
various other reasons.
Yeah, the thing is you really need to completely drop the old indexes
before even starting your application (we have a console with various admin
features from where we can launch a reindex).
FWIW, I put into production this morning 2 applications using ORM 5 and
Search 5.5. Hope to migrate more of them in the next few months.
--
Guillaume
3138
days inactive
3143
days old
4 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Guillaume Smet -
Gustavo Fernandes -
Sanne Grinovero