[
https://issues.apache.org/jira/browse/OFBIZ-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Gray updated OFBIZ-3880:
------------------------------
Component/s: framework
> EntityDateFilterCondition causes the entity cache to return false matches
> -------------------------------------------------------------------------
>
> Key: OFBIZ-3880
> URL: https://issues.apache.org/jira/browse/OFBIZ-3880
> Project: OFBiz
> Issue Type: Bug
> Components: framework
> Reporter: Scott Gray
>
> The EntityDateFilterCondition can cause problems when used as a condition in
> cache queries because it does not internally store the right hand side of the
> query (i.e. the moment in time to filter against). The result is that all
> instances using the same field names (e.g. "fromDate" and "thruDate") are
> considered equal by the equals(Object) method regardless of the moment in
> time that they ultimately end up querying.
> The end result of this is that the if a value is cached against an
> EntityCondition and that condition contains a EntityDateFilterCondition then
> that value could be returned even if would not satisfy the same condition
> queried against the database.
> Concrete example:
> - You query for PartyRelationship records using an EntityDateFilterCondition
> and use the cache
> - Some time passes and one of the previously returned PartyRelationship
> records has expired i.e. thruDate has been set and passed
> - If you now run the same query again then the expired PartyRelationship
> record will be returned in the results from the cache even though you have
> filtered by date
> Obviously the cache shouldn't be being used in combination with an
> EntityDateFilterCondition anyway (in its current state at least) since it is
> impossible to ever retrieve the value from the cache once that moment in time
> has passed (assuming this bug were fixed). But this problem is somewhat
> obscure and it is too easy for a developer to combine the date filter and the
> cache accidentally or without fully thinking it through.
> Proposed fix is to store the moment in time that the condition tests against
> in the object and use it in equals(Object) and hasCode(), should be set
> during init() and cleared during reset().
> But really I don't even understand the purpose of this class, it uses a
> regular EntityCondition internally and we could probably just move the code
> that does the real work (makeCondition(...)) into EntityCondition as a
> utility method or even into EntityUtil and then discard this class entirely.
> Thoughts welcome.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
