SQL generation error

[David Minor <da...@gmail.com>]

I've encountered a SQL generation bug where a join to a superclass seems to
be missing. The problem only occurs when the datacache is in use, and seems
to occur when the superclass is loading a single field which is to-many (I'm
using parallel eager select, which may be affecting this as well). The field
is a collection of the same type as the superclass.

I believe the problem is in the select generated by the
eagerToMany.selectEagerJoin() call in JDBCStoreManager.select(). However,
I've found that in JDBCStoreManager.selectBaseMappings(), if I change the
line:

            if (fms[i] == eagerToMany)
                continue;

to:

            if (fms[i] == eagerToMany) {
                seld = 0;
                continue;
            }

to indicate that the select is required, the problem goes away. However, I
don't know the ramifications on other SQL generation.

If anyone who is more familiar with the SQL generation code could comment,
it would be much appreciated.

-- 
_____________
David Minor

Re: SQL generation error

[Kevin Sutter <kw...@gmail.com>]

Hi David,
More questions than answers...  Can you provide a concrete example of this
failure?  For example, the Entity and Superclass definitions would be
helpful.  The persistence.xml would also be helpful.  So, you are indicating
that if turn on the openjpa.DataCache property, then the problem surfaces?
But, if you remove this property, then everything works as expected?  The
DataCache property automatically turns on the QueryCache, have your tried
setting the openjpa.QueryCache to "false" while leaving the
openjpa.DataCache set to "true"?

Is this particular SQL generated incorrectly all the time?  That is, if you
have the proper settings to reproduce the problem (DataCache, whatever),
does your application always generate the wrong SQL?  Or, is it sometimes
correct?  (The reason I am asking this question is whether the QuerySQLCache
is affecting this scenario or not.  You could quickly test this out by
setting openjpa.jdbc.QuerySQLCache to "false".)

Oh yeah, and what version of OpenJPA are you using?

The concern with the change you suggested below is that we might be
generating or re-generating SQL too often with the proposed change.  But, I
haven't studied it in great depth due to the questions I had above.  If you
have made the change below, how does the rest of the OpenJPA test bucket
fare?  Any regressions introduced when you run the whole bucket?

Thanks,
Kevin

On Mon, Aug 3, 2009 at 2:36 PM, David Minor <da...@gmail.com> wrote:

> I've encountered a SQL generation bug where a join to a superclass seems to
> be missing. The problem only occurs when the datacache is in use, and seems
> to occur when the superclass is loading a single field which is to-many
> (I'm
> using parallel eager select, which may be affecting this as well). The
> field
> is a collection of the same type as the superclass.
>
> I believe the problem is in the select generated by the
> eagerToMany.selectEagerJoin() call in JDBCStoreManager.select(). However,
> I've found that in JDBCStoreManager.selectBaseMappings(), if I change the
> line:
>
>            if (fms[i] == eagerToMany)
>                continue;
>
> to:
>
>            if (fms[i] == eagerToMany) {
>                seld = 0;
>                continue;
>            }
>
> to indicate that the select is required, the problem goes away. However, I
> don't know the ramifications on other SQL generation.
>
> If anyone who is more familiar with the SQL generation code could comment,
> it would be much appreciated.
>
> --
> _____________
> David Minor
>