Remember there's a tradeoff between giving away power and keeping things simple.

I'm not thrilled about allowing to override object initializers w/o a strong use case; not least this would probably have to expose several internals as API to allow people full flexibility.

Building on multi-get seems a cool cleanup and leverage any optimisations ORM/OGM might have, without additional things to learn for the end user.

A user was asking about getTuple() requests being issued from a HSEARCH query instead of getTuples() although his dialect implements MultiGetGridDialect. I also had been contemplating this improvement long time ago and even believed I had filed an issue for it, but I couldn't find it.

Yes, using multi-get would be nice, we don't implement it in OGM yet. Should be straight forward to do. Nevertheless it'd be nice to have some freedom for custom object initializers, beyond the existing fixed impls.

Good point, how did you notice this?

I suspect the better way to implement this is to have Search use the new ORM's capability of "multi-get", and have OGM implement that operation effectively. Linking to HSEARCH-2088.

N.B. Infinispan Query is already able to perform a multi-fetch; it doesn't use the hibernate-search-orm module though.