[EJB 3.0] - Creating SqlResultSetMapping on the fly?
by rjstanford
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 :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135050#4135050
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135050
18 years, 1 month
[EJB 3.0] - Re: Storing user info on server
by jwcone
"roeladriaensens" wrote : What about simply using a custom principal on server side, one that contains your user information?
I considered this, but didn't pursue it because it seemed like I would be using the Principal for a purpose it wasn't really intended for. That is, for some types of user information (e.g. a SSN), a custom Principal is appropriate. However, I'm also talking about a more variable, cache-like approach (e.g. storing the currently active account that's being accessed, or a list of account codes the authenticated user is allowed to access -- in my project, a user can access multiple "accounts" which correspond to different database resources, among other things).
I guess it would still work. I haven't created a custom Principal, before, though. If I were to do this, would I have any difficulty using the custom Principal as a cache that could be read and written to at run-time (e.g. if the authenticated user changed to a different active account, for example).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135029#4135029
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135029
18 years, 1 month