HHH-17956 Criteria multiselect ignores type of the criteria query and always returns list of Object[]

[beikov]

https://hibernate.atlassian.net/browse/HHH-17956

[gavinking]

@beikov please also consider what happens with the following code:

var query = factory.getCriteriaBuilder().createQuery(String[].class);
var bookRoot = query.from(Book.class);
query.multiselect(bookRoot.get("isbn"), bookRoot.get("title"), bookRoot.get("pages"));
var resultList = entityManager.createQuery(query).getResultList();

This should throw a meaningful error stating that Book.pages is not of type String.

If we're going to allow this sort of thing, then we need to check upfront that the type of the Selections passed to multiselect() are actually assignable to the element type of the array.

This was previously not necessary because we assumed that the array type was always Object[].

[gavinking]

A second item of feedback is: even the javadoc of multiselect() doesn't suggest that primitive arrays should be supported here. Quote:

If the type of the criteria query is CriteriaQuery<X[]> for some class X, an instance of type X[] will be returned for each row.

And I don't think primitive arrays make sense because it's pretty hard for us to validate that a Selection<Integer> is non-null.

Furthermore, it seems that the support for primitive arrays is leading to most of the complexity in this PR. If support for primitive arrays were removed, I guess this would be a whole lot simpler, no?

[beikov]

And I don't think primitive arrays make sense because it's pretty hard for us to validate that a Selection<Integer> is non-null.

If users requests an int[] as result type, they must ensure the values are non-null.

Furthermore, it seems that the support for primitive arrays is leading to most of the complexity in this PR. If support for primitive arrays were removed, I guess this would be a whole lot simpler, no?

Of course handling primitive arrays requires more code, but I think it's useful and our session with @franz1981 has shown that performance is not an issue, so we might as well do it IMO.

EDIT: ... requires more code to be efficient, ...

[gavinking]

I think it's useful

It seems to me that the complexity/usefulness ratio here is really quite high.