Max, I would say don't do anything until we nail down what will be specified in JSR-220. My latest refactorings were designed to allow the kind of result set column alias mappings that I proposed to the EG. I think it is perfectly manageable, if you assume sensible defaults (ie. that the default result set column name is the same as the mapped column name).
By the way, do *not* use WrappedResultSet for this, you must use ResultSetDescriptor, together with the new CustomLoader. Don't use the BasicLoader hierarchy at all.
Max Rydahl Andersen wrote:
Hi Guys,
It must be the holidays that make me go revisiting stuff ,)
This time it is SP support in H3. I *think* I can add it in a couple of hours (at least as a first attempt ,),
but want to throw the issues/solution out there for you to look at before doing the necessary changes.
Currently we CUD support, and are missing the R (read, querying) support.
We have two "blockers" preventing us from doing this:
#1 Important database vendors (read oracle) has proprietary methods for preparing and retreving a resultset from a CallableStatement.
(see http://www.enterprisedt.com/publications/oracle/result_set.html)
#2 Since Hibernate requires specific (not-visible-to-users) aliases we dont have any way for users to specify which resultset column should map to a certain alias.
(in SQLLoader this is "solved" by having users insert {entitynameref.propertyname} syntax into the sql string)
Ok - so what to do about this:
For #1 it seems sufficient that we add Dialect controlled preparation of CallableStatements (basically registrering an outParameter in oracle) to Loader.prepareQueryStatement() and in getResultSet() we either call executeQuery() or execute() depending on what Dialect wants.
This will allow us to mark <sql-query>'s as callable and execute them as such.
#2 is worse since much of the code assumes special alias names for columns that in SP's normally would just be a column name (USERNAME vs. USERNAME_x1)....but two things has arrived recently that makes this much easier - WrappedResultset and ResultSetDescriptor (the last one I actually just discovered while writing this email, so now I got 2 solutions for #2)
Today we do the following:
<sql-query name="namedsql">
<return alias="category" class="org.hibernate.test.legacy.Category"/>
<return alias="assignable" class="org.hibernate.test.legacy.Assignable"/> select {category.*}, {assignable.*} from Category {category}, "assign-able" {assignable} where Category.x = :someparameter
</sql-query>
We convert the {}'s to the aliases hibernate need. With SP's we (or rather users) don't have a natural place and "liberty" to put in the alias
conversion.
My original idea were to use WrappedResultSet to add a custom mapping from hibernate wanted aliasname to the userdriven name in the SP.
This would be specified in <sql-query> with something like this:
<sql-query name="queryStuffWithSP">
<return alias="category" class="org.hibernate.test.legacy.Category">
<!-- some syntax for mapping properties/columns to whatever the returned resultset contains -->
</return>
<return alias="assignable" class="org.hibernate.test.legacy.Assignable">
<!-- nothing specified assume alias==columname -->
</return>
{ ? = call queryStuffSP(:named,:parameters,:workshere,:too)}
</sql-query>
...but this leads to kind'a "double-mapping" because the users has already specifiec that name-to-alias binding before (in the class mapping) and when thinking about multicolumned properties it gets even worse and more redundant. So, I will look into extract that information automatically and be the default...so i'll simply assume the column names specified in the mapping for the entity is the exact same, but allow users to override it via "some syntax for mapping..."-segment which I haven't yet found a good way of specifying (any ideas ?)
The second idea is similar for the user as above, but i'll simply use the new ResultSetDescriptor to handle the mapping (much cleaner and performant ,)
(one could argue we might should also add a more SQL specific StoredProcedurePersister and allow users to map usertypes etc. directly to stored procedures - but I don't think that will be of much benefit compared to having SP support (or rather callable-support) in the default persister/loader hiearchy since I think that most users use a mix of SP's and good-old-sql - but that's just me, what do you think/know ?)
This turned into a rather long mail - but I hope you get the idea....comments are very welcome - especially on a syntax for the "alias-to-column" ...
-- Gavin King +61 410 534 454 +1 404 822 8349 callto://gavinking
Hibernate [EMAIL PROTECTED] http://hibernate.org
JBoss Inc [EMAIL PROTECTED] http://jboss.com
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
