Hi,
I just ran into what I believe is a bug with the prepared SQL code. In
PreparedQueryImpl.reparameterize(), we have the following code:
> if (ImplHelper.isManageable(val)) {
> setPersistenceCapableParameter(result, val, indices, broker);
> } else if (val instanceof Collection) {
> setCollectionValuedParameter(result, (Collection)val, indices,
> key);
> }
This does not work if the parameter is a collection of persistence-capable
objects, as setCollectionValuedParameter assumes that the values are not PCs.
Is this expected, or am I running into a limitation of the prepared SQL work?
I briefly looked at patching this by modifying / refactoring setPCParameter()
so that I could invoke it from setCollectionValuedParameter(), but I'm confused
by another couple aspects of the prepared SQL code that I wanted to get my head
around first:
1. The query framework already knows how to convert a PC parameter into values;
I'm a bit surprised to see this code replicated in another part of the
framework. Additionally, I was surprised to see direct prepared SQL checks in
the openjpa-persistence module -- seems like this would pretty fully belong in
openjpa-jdbc. Do we have any design discussions that I can review to better
understand the work?
2. My query looks something like this:
> select e from Entity e where e.child in :children
Then, I execute the query with a Set<Child>, where Child is a persistent type
also. The query is translated into a SELECT statement with a single parameter,
as expected. However, the Set<Child> value itself is un-boxed, and it looks
like that (unboxed) value is pushed down into the SELECT statement. Which, as
far as I can tell, would mean that 'in' clauses won't work as expected.
Have we done any testing with multi-valued 'in' clauses + prepared SQL?
Thanks,
-Patrick
--
Patrick Linskey
202 669 5907
