[hibernate-dev] Some migration pains HSearch 5

[Sanne Grinovero]

Thanks a lot Marc, that's very useful.
Some comments inline:

On 29 January 2015 at 19:27, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> So, I've started migrating our production environment to HSearch 5 at long
> last.
>
> Some of the initial pains that may warrant some documentation love:
>
> * @IndexedEmbedded basically inverts the default because before HSearch 5,
> the default was essentially: @IndexedEmbedded(includeEmbeddedObjectId=true),
> whereas now it's essentially: @IndexedEmbedded(includeEmbeddedObjectId=false).
> Inverting defaults seems like a dangerous upgrade choice to me.

Sorry we missed this in the Migration Guide. I've added it right now.

> * I use a lot of indexedEmbedded(includePaths="id")  style includes.
>
> public class MyClass{
>
> @Id
> @GeneratedValue(strategy = GenerationType.AUTO)
> @Column(name="userId", nullable=false, insertable=false, updatable=false)
> @DocumentId
> public Long getId() {
>    return id;
> }
>
> }
>
> I always queried these as follows:
>
> qb.keyword().onField("id").matching(myLongId).createQuery()
>
> where the Long would implicitly converted to a String. and the term query
> would be
>
> +id:1
>
> Now, it becomes a NumericRangeQuery based on the fact that I'm passing a
> Long. But DocumentIds apparently are still strings by default. And this
> query will fail to deliver results.
>
> It makes most sense to me to convert DocumentId to NumericFields and adding
> @NumericField to it seems to fix it, but I'm not sure if this could create
> problems in other areas since this is the documentId. Anyway, this is
> undocumented.

That's an ok workaround which should not cause other problems, but is
rather redundant so your resulting index is a bit larger than strictly
needed.

It's definitely unintended, I've opened a bug:
https://hibernate.atlassian.net/browse/HSEARCH-1791

>
> * The way to access a MutableSearchFactory has changed and is not
> documented. This is more of an edge case

Do you need any pointer to do that? Glad to help out, however we don't
consider it public API.
Could you describe what you need that for?

Thanks again!
Sanne

>
> That's it for now.
>
> Cheers,
>
> Marc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev