[
https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592712#action_12592712
]
Patrick Linskey commented on OPENJPA-407:
-----------------------------------------
More comments:
- In JDBCConfigurationImpl: you've hard-coded the query sql cache to be a
HashMap. Generally, we've tried to use the plugin infrastructure to allow
people to vary the implementations based on their needs. It looks like you've
taken this into account in your plugin class, but you never use the
newInstance() method of that class, so my read is that the value will always be
the hard-coded HashMap.
- In JDBCFetchConfigurationImpl.JDBCConfigurationState, is there any reason why
equals() and hashCode() for the inner class don't consider the fetchInnerJoins
field? Also, in general, I try to keep the ordering of fields the same between
the equals() / hashCode() block and the declarations, to make it easier to spot
these sorts of differences.
- In JDBCFetchConfigurationImpl, it's surprising that the equals() and
hashCode() only consider fetch groups, and not any of the other things in
JDBCFetchConfiguration or its superclass. What's the rationale behind that?
More comments to come. In general, it looks like a promising approach, but I
need to do more reading. Also, I've sent off a build with the patch to our
performance team to run through some internal tests.
> 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, OPENJPA-407.patch,
> OPENJPA-407.patch, QuerySQLCache.doc
>
>
> 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.
