Dave-
I'm using 5.0.27-standard, so perhaps that bug is not the problem --
or it wasn't fixed.
If it's not working for MySQL 5, can you file an OpenJPA JIRA report
for this at https://issues.apache.org/jira/browse/OPENJPA ? We should
probably try to figure out some way to work around the limitation.
Is it possible to turn off OpenJPA generated sub-selects and only do a
sub-select when an application query uses one? That's the default
behavior in Toplink/JPA.
If you set the DBDictionary parameter to SupportsSubselect=false,
then we won't generate the subselect (although we'll probably just
wind up having to perform the operation in-memory, which is usually
slower). Unfortunately, we'll probably also throw an exception when
you try to actually execute a subselect against the database.
On Mar 17, 2007, at 6:19 AM, Dave wrote:
On 3/16/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:
This does look like a bug in MySQL (see http://bugs.mysql.com/
bug.php?
id=5037 ). Supposedly this is fixed in as of version 5.0.20.
Thanks for looking into this.
I'm using 5.0.27-standard, so perhaps that bug is not the problem --
or it wasn't fixed.
In general, we use subselects for bulk operations because delete and
update SQL statements do not allow the specification of multiple
tables, so only the simplest bulk operations would be possible
without the ability to use subselects.
Is it possible to turn off OpenJPA generated sub-selects and only do a
sub-select when an application query uses one? That's the default
behavior in Toplink/JPA.
- Dave
