Screen based cache recommendation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Screen based cache recommendation

Bob Morley
We have been spending some time looking at caching in Ofbiz.  One pattern that we have seen in services is to perform a query (with caching on) and then on the result apply EntityUtil.filterByDate (to restrict to non-expired records).  We believe this is because including the "filter by date" constraint via the delegator call would result in caching very occurring (as the current date/time would be changing with each request).

However, this pattern does not seem to be applied from the screens.  You could apply a similar method to enable caching and then filter client side; but each screen would have to coded as such.  Our recommendation is when "entity-condition" and "entity-and" and have been set to "filter-by-date" as well as "use-cache" are set to true, we would create the delegator condition to _not_ include the date, but then provide the client-side filtering.

We believe this enhancement would allow us to leverage caching with entity conditions that want to restrict by current date/time.

If we go ahead and create a JIRA and package this up; does the community think this would be valuable?
Reply | Threaded
Open this post in threaded view
|

Re: Screen based cache recommendation

David E. Jones-2

On Oct 26, 2009, at 8:55 AM, Bob Morley wrote:

>
> We have been spending some time looking at caching in Ofbiz.  One  
> pattern
> that we have seen in services is to perform a query (with caching  
> on) and
> then on the result apply EntityUtil.filterByDate (to restrict to non-
> expired
> records).  We believe this is because including the "filter by date"
> constraint via the delegator call would result in caching very  
> occurring (as
> the current date/time would be changing with each request).
>
> However, this pattern does not seem to be applied from the screens.  
> You
> could apply a similar method to enable caching and then filter  
> client side;
> but each screen would have to coded as such.  Our recommendation is  
> when
> "entity-condition" and "entity-and" and have been set to "filter-by-
> date" as
> well as "use-cache" are set to true, we would create the delegator  
> condition
> to _not_ include the date, but then provide the client-side filtering.
>
> We believe this enhancement would allow us to leverage caching with  
> entity
> conditions that want to restrict by current date/time.
>
> If we go ahead and create a JIRA and package this up; does the  
> community
> think this would be valuable?

Yes, that sounds fine to me and would be a good improvement.

-David

Reply | Threaded
Open this post in threaded view
|

Re: Screen based cache recommendation

Bob Morley
I have created a JIRA for this improvement -> https://issues.apache.org/jira/browse/OFBIZ-3090 and we will attach the patch once the work is completed.

David E Jones-4 wrote
On Oct 26, 2009, at 8:55 AM, Bob Morley wrote:

>
> We have been spending some time looking at caching in Ofbiz.  One  
> pattern
> that we have seen in services is to perform a query (with caching  
> on) and
> then on the result apply EntityUtil.filterByDate (to restrict to non-
> expired
> records).  We believe this is because including the "filter by date"
> constraint via the delegator call would result in caching very  
> occurring (as
> the current date/time would be changing with each request).
>
> However, this pattern does not seem to be applied from the screens.  
> You
> could apply a similar method to enable caching and then filter  
> client side;
> but each screen would have to coded as such.  Our recommendation is  
> when
> "entity-condition" and "entity-and" and have been set to "filter-by-
> date" as
> well as "use-cache" are set to true, we would create the delegator  
> condition
> to _not_ include the date, but then provide the client-side filtering.
>
> We believe this enhancement would allow us to leverage caching with  
> entity
> conditions that want to restrict by current date/time.
>
> If we go ahead and create a JIRA and package this up; does the  
> community
> think this would be valuable?

Yes, that sounds fine to me and would be a good improvement.

-David
Reply | Threaded
Open this post in threaded view
|

Re: Screen based cache recommendation

Bob Morley
Ok David, this is a very small change and since you thought it was a good idea I am sure you will assign the JIRA to you and get it committed.  :)

https://issues.apache.org/jira/browse/OFBIZ-3090

Bob Morley wrote
I have created a JIRA for this improvement -> https://issues.apache.org/jira/browse/OFBIZ-3090 and we will attach the patch once the work is completed.

David E Jones-4 wrote
On Oct 26, 2009, at 8:55 AM, Bob Morley wrote:

>
> We have been spending some time looking at caching in Ofbiz.  One  
> pattern
> that we have seen in services is to perform a query (with caching  
> on) and
> then on the result apply EntityUtil.filterByDate (to restrict to non-
> expired
> records).  We believe this is because including the "filter by date"
> constraint via the delegator call would result in caching very  
> occurring (as
> the current date/time would be changing with each request).
>
> However, this pattern does not seem to be applied from the screens.  
> You
> could apply a similar method to enable caching and then filter  
> client side;
> but each screen would have to coded as such.  Our recommendation is  
> when
> "entity-condition" and "entity-and" and have been set to "filter-by-
> date" as
> well as "use-cache" are set to true, we would create the delegator  
> condition
> to _not_ include the date, but then provide the client-side filtering.
>
> We believe this enhancement would allow us to leverage caching with  
> entity
> conditions that want to restrict by current date/time.
>
> If we go ahead and create a JIRA and package this up; does the  
> community
> think this would be valuable?

Yes, that sounds fine to me and would be a good improvement.

-David