[
https://issues.apache.org/jira/browse/OPENJPA-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592896#action_12592896
]
Patrick Linskey commented on OPENJPA-407:
-----------------------------------------
> Perhaps we need to add a document indicating that the hashCode
> and equals methods in JDBCFetchConfigurationImpl are used in
> querySQLCache for findBy operation.
I'm a bit nervous about having equals() and hashCode() (which are by convention
deemed to apply to an entire instance) only be meaningful in certain contexts.
I think that it would make more sense to create some sort of inner cache key
class whose equals() and hashCode() are custom-designed for the purposes of
this cache.
> Any other usage of hashCode/equals should consider the fetchInnderJoin?
This change actually interfered with my OPENJPA-522 fix; I ended up switching
to an IdentityHashMap to avoid the issue. At the time, I did not realize that
the addition of equals() / hashCode() had caused this. I would not be surprised
if there are other places in OpenJPA that implicitly make assumptions about
equals() and hashCode() behavior for FetchConfigurations, although I can't
think of any offhand.
In general, I'm not a huge fan of equals() / hashCode() methods (and especially
hashCode()) that change in value over the lifecycle of the object; this tends
to make it very hard to put these types into data structures.
> (5) In terms of which fields will go into the calcuation of hashcode and
> equals, we are
> considering those fields that can be changed at the runtime via FetchPlan,
> since these
> will be directly affect the generated sql. For those which could not be
> changed at runtime,
> we are not including them in the hashcode or equals, hoping in doing so, we
> could
> minimize the effort in the calculation of cache key.
As I mentioned above, this seems fair for the purposes of a cache key, but not
appropriate for the general equals() / hashCode() implementation for the
instance.
> 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.
