I've currently got a native query that, as normal, is generating a List<Object>. It's dynamically created, and the number of columns returned will change based on the user request (this is part of our reporting engine). That works well.
My actual goal is to modify the return types so that, for example, instead of returning two columns "currency" and "amount" in the middle of the array, I can return a single column "money" that takes those properties. The Money class that we have is an @Embedded object.
If I always knew the columns that would be returned, I could use an @SqlResultSetMapping annotation to define a mapping, then refer to that mapping by name in createNativeQuery(sql, mapping). Unfortunately, I don't.
It looks like I can drop down and get the actual Hibernate session, then use Hibernate's addScalar() and addEntity() to the Hibernate Query object to achieve the same results (although I haven't yet confirmed that addEntity will work with embedded objects, and I don't really want them to be managed, just created).
Still, I hate adding Hibernate-specific code for no reason. Is there any way - any way at all - to achieve my goals without doing this? It seems pretty bizarre that the only option for sql mapping is to predefine it using annotations and that there is no procedural way to define one on the fly (and then discard it).
As always, your advice is welcome - thanks!
ps - my other thought was to create my own List implementation that contains some app-supplied metadata and effectively wraps the returned Object so that my bean actually returns a List of CustomList (actual notation squicking the BB even with HTML/BBCode disabled) instead of List<Object> - the CustomList could then, on each row requested, map the (eg) 60 column result set into the correct 59 column result set, creating the Money object (and others) as necessary. This seems like code that I'd like the framework to make redundant, though. Still, if that's the best way to go, that feedback is useful too :)