StoredProcedureQuery spq = ...; spq.registerStoredProcedureParameter( 1, Calendar.class, ParameterMode.IN ); spq.setParameter( 1, aGregorianCalendar, TemporalType.DATE );
We have some failures against the TCK for this scenario. There are 2 ways to solve this, and I wanted to get opinions on the options. The first approach would be to convert the incoming Calendar to a Date. That is pretty easy and straightforward. A second approach would be to have our TimestampType, DateType, TimeType classes accept the Calendar. There could be a real win here in that this approach would let TimestampType, DateType, TimeType use the form of methods on Statement that accept the Timestamp, Date, Time *plus* a Calendar (for TZ information). So today, for Timestamp e.g., we call: statement.setTimestamp( 1, theTimestamp ) but there is also the form: statement.setTimestamp( 1, theTimestamp, theCalendar ) Of course passing the timezone (via the Calendar) may not be what the user wants :) Probably "safer" going with the first option, just wanted to throw out the second one to see what y'all thought. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
