Fair enough. I can understand the sentiment. I was just justifying why the patch was built against 1.0.x (instead of trunk)....
Kevin On Jan 30, 2008 6:35 PM, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564241#action_12564241] > > Patrick Linskey commented on OPENJPA-407: > ----------------------------------------- > > I haven't read the patch yet; I'll take a look at it later this week. > However, without having looked at it, I'm hesitant about putting something > like this into the 1.0.x branch, as it seems like it's probably a > decently-large behavioral change, and thus likely to introduce instability. > I'd prefer if we tried to keep our maintenance branch changes confined to > bugfixes. Of course, performance issues tend to be hard to classify > concretely as bugs vs. new features. > > > Cache SQL (or closer precursors to SQL) more aggressively > > --------------------------------------------------------- > > > > Key: OPENJPA-407 > > URL: https://issues.apache.org/jira/browse/OPENJPA-407 > > Project: OpenJPA > > Issue Type: Improvement > > Components: jdbc, kernel, query, sql > > Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0 > > Reporter: Patrick Linskey > > Fix For: 1.1.0 > > > > Attachments: findBy.patch, OPENJPA-407.patch > > > > > > When data is not available in the data cache, OpenJPA dynamically > creates SQL to look up the requested data. OpenJPA should more aggressively > cache this SQL to accelerate pathways from a cache miss to the database. > > The generated SQL takes a number of factors into account, including the > requested records, transaction status, currently-loaded data, and the > current fetch configuration. Any caching would need to account for these > factors as well. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
