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 <[email protected]> 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 >
