openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From catalina wei <catalina....@gmail.com>
Subject Re: prepared SQL bug / question
Date Wed, 21 Jul 2010 18:54:21 GMT
Hi Patrick,
OPENJPA-1738 is open for this bug.

Catalina

On Mon, Jul 19, 2010 at 4:04 PM, Patrick Linskey <plinskey@gmail.com> wrote:

> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message