javax.persistence.Query#setLockMode and native (SQL) queries
by Steve Ebersole
The spec specifically says that javax.persistence.Query#setLockMode
should throw an IllesgalStateException when called on a query that
represents a native query. Our implementation has not done that
historically since we do have (to varying degrees) the ability to apply
locking to the SQL.
However the 2.1 TCK is checking this and we are failing because we do
not throw the IllesgalStateException :(
So I changed up our impl to throw the IllesgalStateException to pass the
TCK. I did add a new query hint to allow users who might be relying on
this to keep on trucking. So instead of:
Query q = em.createNative( query );
// this is what is illegal
q.setLockMode( theLockMode );
users would need to do:
Query q = em.createNative( query );
q.setHint( QueryHints.NATIVE_LOCKMODE, theLockMode );
Just an FYI...
12 years, 3 months
AttributeConverters and AnnotationBinder part 2 : Collections
by Steve Ebersole
So what I did earlier does not work for Collections. Collections go
through a very different code path (even ElementCollection which i found
very odd). That code does not use the pieces of PropertyBinder and
SimpleValueBinder that got changed.
Even more oddly, the only time I see uses of
PropertyBinder/SimpleValueBinder from collections are for many-to-many
handling:
org.hibernate.cfg.annotations.CollectionBinder#bindManyToManySecondPass.
Or is this just a badly named method that really handles more that just
many-to-many?
12 years, 3 months
AUTO: Mario Briggs is out of the office -
by Mario Ds Briggs
I am out of the office until 09/24/2013.
Dad in hospital. Will check email on and off.
contact Varuna Ps Lakshminarayana/India/IBM or Praveen Devarao/India/IBM
for emergencies
Note: This is an automated response to your message "hibernate-dev Digest,
Vol 87, Issue 20" sent on 20/09/2013 21:30:03.
This is the only notification you will receive while this person is away.
12 years, 3 months
<sql-result-set-mapping/> handling in JPAOverriddenAnnotationReader
by Steve Ebersole
I had to hook into processing <sql-result-set-mapping/> within
JPAOverriddenAnnotationReader so I took the opportunity to reorganize
the code.
As part of that there were 2 pieces of code in particular that I could
not figure out the purpose of:
1) We were excepting <result-class/> as a sub-element of
<sql-result-set-mapping/>. The code even had a comment already
questioning this. This element is not part of the JPA orm.xsd. For now
I removed support for this commenting out the code. If you know why it
was there, or see problems correct it or give me a shout.
2) We were also processing an attribute named 'result-set-mapping' on
<sql-result-set-mapping/>. Not sure what this is about at all. Again
for now I just commented it out.
12 years, 3 months
Re: [hibernate-dev] Function support in ProcedureCall/StoredProcedureQuery
by Hardy Ferentschik
On 19 Jan 2013, at 3:46 PM, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> The trouble is that hints are valid on StoredProcedureQuery whether named or not. If we go the route of using hints for annotations, doesn't it make sense to be consistent and use that when building a StoredProcedureQuery too?
For me a hint is used when applicable, but can be ignored when not. Obviously the documentation would need to explain when and how the hints need to be used.
--Hardy
12 years, 3 months
Function support in ProcedureCall/StoredProcedureQuery
by Steve Ebersole
RE: https://hibernate.atlassian.net/browse/HHH-8445
I'd like to get opinions on this. Essentially the JPA spec
(StoredProcedureQuery) is silent on how/if calling database functions
through this API is supposed to be supported. I asked for clarification
of this from the rest of the EG, but got no responses. So at this point
we are on our own to implement this as we see fit.
And the problem is that we will need to support it. Some databases only
support REF_CURSOR "parameters" via function return. In fact, as far as
I know, only Oracle supports returning cursors from procedures via
parameters (although on HHH-8445 Christian claims DB2 does as well); for
all other databases which support returning cursors at all, doing so
requires a function where the cursor is the function return.
There are 2 aspects to the distinction between a procedure call and a
function call. First is the syntax used. Second is handling of
"parameter registrations".
A procedure is called using the syntax "{call theProcedureName(...)}"; a
function using "{?=call theFunctionName(...)}". Given a call that has
just one "parameter registration" representing a cursor, the difference
would be "{call the_proc(?)}" versus "{?=call the_func()}".
JPA disallows mixing of named and positional parameter registrations
through StoredProcedureQuery. That is potentially a problem here. The
function return is inherently positional (as far as I know the JDBC spec
does not discuss metadata about a function return, let alone naming of
it). If the StoredProcedureQuery is defined using positional
parameters, no problem. If the StoredProcedure is defined using named
parameters, that is where we run into this potential problem mainly
because the spec says that the order in which parameters are registered
is irrelevant.
In my opinion, ideally the JPA spec would have defined a separate method
to register a "function return". Luckily since the spec does not say
anything and the EG never responded we are free to do WhateverMakesSense
:) I have an example of what "providing a separate method to register
the function return" might look like in the comments of HHH-8445.
Ideally we'd allow access to the function return via the same mechanism
as registered "output" (IN/INOUT/REF_CURSOR) parameters. Just not sure
that is possible. The tricky part is that (via JPA StoredProcedureQuery
at least) access to parameter output values are only defined to be
available by name and position.
The other downside to using a separate method, as of now at least, would
be the difficulty to hook in to JPA @NamedStoredProcedureQuery support.
We'd either need to define a new @NamedFunctionCallQuery with explicit
support for defining the function return, or go a different route
altogether (using query hints maybe).
12 years, 3 months
StoredProcedureQuery parameters
by Steve Ebersole
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.
12 years, 3 months
JCP Survey by London Java Community
by Gunnar Morling
Hi all,
I came across an interesting survey conducted by the London Java Community
[1].
When being asked in which area the JCP should develop a standard, 18% of
participants answered with "NoSQL", making this the most popular response,
followed by "Data Analysis and Big Data" and "Platform as a Service (PAAS)
Cloud Computing", with 14% each.
Not sure how representative the survey is, but I conclude there is
definitely interest in in technologies such as OGM and their
standardization.
--Gunnar
[1]
http://londonjavacommunity.wordpress.com/2013/09/16/the-java-community-pr...
12 years, 3 months
