Fwd: Why "never-cache" on OrderHeader and OrderItem?

[byersa]

I am moving this post to dev because I see that "extend-entity" does not
call populateBasicInfo in ModelEntity. I am guessing that there are
properties that you do not want overridden in extend-entity, but I would
like to override "never-cache".

I see that there is a "setNeverCache", but I don't see when it would be
called - when are instances of ModelEntity created - couldn't there be many
of them? When would I apply "setNeverCache"?

Here is what populateBasicInfo sets:
        this.entityName =
UtilXml.checkEmpty(entityElement.getAttribute("entity-name")).intern();
        this.tableName =
UtilXml.checkEmpty(entityElement.getAttribute("table-name"),
ModelUtil.javaNameToDbName(this.entityName)).intern();
        this.packageName =
UtilXml.checkEmpty(entityElement.getAttribute("package-name")).intern();
        this.defaultResourceName =
UtilXml.checkEmpty(entityElement.getAttribute("default-resource-name")).intern();
        this.dependentOn =
UtilXml.checkEmpty(entityElement.getAttribute("dependent-on")).intern();
        this.doLock =
UtilXml.checkBoolean(entityElement.getAttribute("enable-lock"), false);
        this.noAutoStamp =
UtilXml.checkBoolean(entityElement.getAttribute("no-auto-stamp"), false);
        this.neverCache =
UtilXml.checkBoolean(entityElement.getAttribute("never-cache"), false);
        this.autoClearCache =
UtilXml.checkBoolean(entityElement.getAttribute("auto-clear-cache"), true);

Plus it sets sequenceBankSize.
How many, if any, of these fields should be callable from "extend-entity"?

-Al

---------- Forwarded message ----------
From: Al Byers <[hidden email]>
Date: Fri, Mar 13, 2009 at 1:10 AM
Subject: Why "never-cache" on OrderHeader and OrderItem?
To: [hidden email]


What is the general reason for turning cache off?

Why for OrderHeader and OrderItem, in particular?

Can caching be turned on via "extend-entity"?

thanks for any info.

-Al

[David E Jones-3]

Stepping back a little, why do you want to cache data from those  
entities?

-David


On Mar 19, 2009, at 11:13 AM, Al Byers wrote:

> I am moving this post to dev because I see that "extend-entity" does  
> not
> call populateBasicInfo in ModelEntity. I am guessing that there are
> properties that you do not want overridden in extend-entity, but I  
> would
> like to override "never-cache".
>
> I see that there is a "setNeverCache", but I don't see when it would  
> be
> called - when are instances of ModelEntity created - couldn't there  
> be many
> of them? When would I apply "setNeverCache"?
>
> Here is what populateBasicInfo sets:
>        this.entityName =
> UtilXml.checkEmpty(entityElement.getAttribute("entity-
> name")).intern();
>        this.tableName =
> UtilXml.checkEmpty(entityElement.getAttribute("table-name"),
> ModelUtil.javaNameToDbName(this.entityName)).intern();
>        this.packageName =
> UtilXml.checkEmpty(entityElement.getAttribute("package-
> name")).intern();
>        this.defaultResourceName =
> UtilXml.checkEmpty(entityElement.getAttribute("default-resource-
> name")).intern();
>        this.dependentOn =
> UtilXml.checkEmpty(entityElement.getAttribute("dependent-
> on")).intern();
>        this.doLock =
> UtilXml.checkBoolean(entityElement.getAttribute("enable-lock"),  
> false);
>        this.noAutoStamp =
> UtilXml.checkBoolean(entityElement.getAttribute("no-auto-stamp"),  
> false);
>        this.neverCache =
> UtilXml.checkBoolean(entityElement.getAttribute("never-cache"),  
> false);
>        this.autoClearCache =
> UtilXml.checkBoolean(entityElement.getAttribute("auto-clear-cache"),  
> true);
>
> Plus it sets sequenceBankSize.
> How many, if any, of these fields should be callable from "extend-
> entity"?
>
> -Al
>
> ---------- Forwarded message ----------
> From: Al Byers <[hidden email]>
> Date: Fri, Mar 13, 2009 at 1:10 AM
> Subject: Why "never-cache" on OrderHeader and OrderItem?
> To: [hidden email]
>
>
> What is the general reason for turning cache off?
>
> Why for OrderHeader and OrderItem, in particular?
>
> Can caching be turned on via "extend-entity"?
>
> thanks for any info.
>
> -Al

[Adam Heath-2]

David E Jones wrote:
> Stepping back a little, why do you want to cache data from those entities?

Two steps forward, one step back....

Why would you *not* want to?

[David E Jones-3]

On Mar 19, 2009, at 3:04 PM, Adam Heath wrote:

> David E Jones wrote:
>> Stepping back a little, why do you want to cache data from those  
>> entities?
>
> Two steps forward, one step back....
>
> Why would you *not* want to?

Sorry, I asked first and I want to hear someone's understand of when  
it's actually helpful to use a cache, especially for something like  
order or party entities...

If someone wants to hear my thoughts on when it is helpful to use a  
cache, well... the mailing list archives probably have a dozen such  
comments (related to frequency of access versus change, access  
population size versus change population size, sensitivity to being  
stale, etc).

-David

[byersa]

We are modeling the delivery of online exams using OrderHeader and
OrderItem. The client needs to check often to see if the statusId has been
changed by the supervisor.

Would we be better off to create another entity, keyed by orderId and
orderItemSeqId, just for this purpose?

-Al

On Thu, Mar 19, 2009 at 2:24 PM, David E Jones
<[hidden email]>wrote:

>
> Stepping back a little, why do you want to cache data from those entities?
>
> -David
>
>
>
> On Mar 19, 2009, at 11:13 AM, Al Byers wrote:
>
>  I am moving this post to dev because I see that "extend-entity" does not
>> call populateBasicInfo in ModelEntity. I am guessing that there are
>> properties that you do not want overridden in extend-entity, but I would
>> like to override "never-cache".
>>
>> I see that there is a "setNeverCache", but I don't see when it would be
>> called - when are instances of ModelEntity created - couldn't there be
>> many
>> of them? When would I apply "setNeverCache"?
>>
>> Here is what populateBasicInfo sets:
>>       this.entityName =
>> UtilXml.checkEmpty(entityElement.getAttribute("entity-name")).intern();
>>       this.tableName =
>> UtilXml.checkEmpty(entityElement.getAttribute("table-name"),
>> ModelUtil.javaNameToDbName(this.entityName)).intern();
>>       this.packageName =
>> UtilXml.checkEmpty(entityElement.getAttribute("package-name")).intern();
>>       this.defaultResourceName =
>>
>> UtilXml.checkEmpty(entityElement.getAttribute("default-resource-name")).intern();
>>       this.dependentOn =
>> UtilXml.checkEmpty(entityElement.getAttribute("dependent-on")).intern();
>>       this.doLock =
>> UtilXml.checkBoolean(entityElement.getAttribute("enable-lock"), false);
>>       this.noAutoStamp =
>> UtilXml.checkBoolean(entityElement.getAttribute("no-auto-stamp"), false);
>>       this.neverCache =
>> UtilXml.checkBoolean(entityElement.getAttribute("never-cache"), false);
>>       this.autoClearCache =
>> UtilXml.checkBoolean(entityElement.getAttribute("auto-clear-cache"),
>> true);
>>
>> Plus it sets sequenceBankSize.
>> How many, if any, of these fields should be callable from "extend-entity"?
>>
>> -Al
>>
>> ---------- Forwarded message ----------
>> From: Al Byers <[hidden email]>
>> Date: Fri, Mar 13, 2009 at 1:10 AM
>> Subject: Why "never-cache" on OrderHeader and OrderItem?
>> To: [hidden email]
>>
>>
>> What is the general reason for turning cache off?
>>
>> Why for OrderHeader and OrderItem, in particular?
>>
>> Can caching be turned on via "extend-entity"?
>>
>> thanks for any info.
>>
>> -Al
>>
>
>

[Adam Heath-2]

David E Jones wrote:

>
> On Mar 19, 2009, at 3:04 PM, Adam Heath wrote:
>
>> David E Jones wrote:
>>> Stepping back a little, why do you want to cache data from those
>>> entities?
>>
>> Two steps forward, one step back....
>>
>> Why would you *not* want to?
>
> Sorry, I asked first and I want to hear someone's understand of when
> it's actually helpful to use a cache, especially for something like
> order or party entities...
>
> If someone wants to hear my thoughts on when it is helpful to use a
> cache, well... the mailing list archives probably have a dozen such
> comments (related to frequency of access versus change, access
> population size versus change population size, sensitivity to being
> stale, etc).

Bother, I hate discussions like this.

If you know something, if you know the reason, if you know why, why
must it be difficult for you to tell what you know?  Why must others
try to infer what is going on inside your mind?

If I know the answer to a question, why would I redirect said question
to other resources?  That just wastes the asker's time.  Just give
them the answer, so they can get back to whatever they were doing before.

With that out of the way...

By default entities are cached.  The default in the dtd means to allow
caching.  It takes an explicit change to disable the cache.  There
must have been some reason why this explicit cache disable was done.
Wouldn't it be useful if such a policy decision was documented, if the
reasons why were written down somewhere?

Since ofbiz sets the default for entity caching to on, ofbiz obviously
 considers entity caching to be worthwhile.

ps: I hate meta-discussions.  But unless they occur, bad communication
will continue to happen.

[David E Jones-3]

On Mar 19, 2009, at 7:03 PM, Adam Heath wrote:

> David E Jones wrote:
>>
>> On Mar 19, 2009, at 3:04 PM, Adam Heath wrote:
>>
>>> David E Jones wrote:
>>>> Stepping back a little, why do you want to cache data from those
>>>> entities?
>>>
>>> Two steps forward, one step back....
>>>
>>> Why would you *not* want to?
>>
>> Sorry, I asked first and I want to hear someone's understand of when
>> it's actually helpful to use a cache, especially for something like
>> order or party entities...
>>
>> If someone wants to hear my thoughts on when it is helpful to use a
>> cache, well... the mailing list archives probably have a dozen such
>> comments (related to frequency of access versus change, access
>> population size versus change population size, sensitivity to being
>> stale, etc).
>
> Bother, I hate discussions like this.
>
> If you know something, if you know the reason, if you know why, why
> must it be difficult for you to tell what you know?  Why must others
> try to infer what is going on inside your mind?

Hmmm... isn't it YOU who is asking ME to guess what is going inside  
Al's mind? Remember, I asked him a question, namely to provide more  
information about what he is trying to do so that I can comment  
because the information provided so far was not adequate for comment.

Do you have an issue with that? Am I supposed to be some sort of  
omniscient?

> If I know the answer to a question, why would I redirect said question
> to other resources?  That just wastes the asker's time.  Just give
> them the answer, so they can get back to whatever they were doing  
> before.
>
> With that out of the way...

Yes...

> By default entities are cached.

Actually by default all entities are "cachable", not "cached". That is  
up to the code.

> The default in the dtd means to allow
> caching.  It takes an explicit change to disable the cache.  There
> must have been some reason why this explicit cache disable was done.
> Wouldn't it be useful if such a policy decision was documented, if the
> reasons why were written down somewhere?

Sounds good. Is that something you are saying you'd like to work on?

> Since ofbiz sets the default for entity caching to on, ofbiz obviously
> considers entity caching to be worthwhile.

I don't understand how this is relevant... but please do share more on  
the topic!

> ps: I hate meta-discussions.  But unless they occur, bad communication
> will continue to happen.

Yes, which is why I was asking for DETAILS in the first place...

-David

[David E Jones-3]

Interesting. Are you running into performance problems with that or  
something?

The reason I ask is because this doesn't seem to meet the criteria for  
being a good use of a cache.

Read versus write frequency: More reads than writes, but it's not  
clear if it's enough for a +1 on this; usually for this to be an  
effective plus you need a LOT more reads than writes (+1, possibly +0)
Population size, consumers versus producers: not sure based on what  
you write, but it sounds like they are fairly equal in size (+0,  
possibly -1)
Sensitivity to stale data: somewhat sensitive to stale data (-1)

As to implementation details: While we could support overriding this  
attribute in the extend-entity, you could also just patch the  
entitymodel.xml file to modify that one line during your build  
process, or however you are managing base ofbiz changes.

Whether or not OrderHeader/Item are good choices for your application  
is another question altogether, and one that to answer properly would  
require a good deal more information, like ORM-style statements about  
the information you need to keep track of and how it relates to other  
information.

Anyway, whatever the case, best of luck with it. This sounds like a  
"gray area" scenario, and I guess if I were facing it I'd do some  
performance testing to establish a baseline that shows the performance  
problem, and then see if introducing the cache actually helps.  
Actually, I guess if I were to decide on something like this the  
possible stale cache issue would be a show-stopper.

-David


On Mar 19, 2009, at 3:59 PM, Al Byers wrote:

> We are modeling the delivery of online exams using OrderHeader and
> OrderItem. The client needs to check often to see if the statusId  
> has been
> changed by the supervisor.
>
> Would we be better off to create another entity, keyed by orderId and
> orderItemSeqId, just for this purpose?
>
> -Al
>
> On Thu, Mar 19, 2009 at 2:24 PM, David E Jones
> <[hidden email]>wrote:
>
>>
>> Stepping back a little, why do you want to cache data from those  
>> entities?
>>
>> -David
>>
>>
>>
>> On Mar 19, 2009, at 11:13 AM, Al Byers wrote:
>>
>> I am moving this post to dev because I see that "extend-entity"  
>> does not
>>> call populateBasicInfo in ModelEntity. I am guessing that there are
>>> properties that you do not want overridden in extend-entity, but I  
>>> would
>>> like to override "never-cache".
>>>
>>> I see that there is a "setNeverCache", but I don't see when it  
>>> would be
>>> called - when are instances of ModelEntity created - couldn't  
>>> there be
>>> many
>>> of them? When would I apply "setNeverCache"?
>>>
>>> Here is what populateBasicInfo sets:
>>>      this.entityName =
>>> UtilXml.checkEmpty(entityElement.getAttribute("entity-
>>> name")).intern();
>>>      this.tableName =
>>> UtilXml.checkEmpty(entityElement.getAttribute("table-name"),
>>> ModelUtil.javaNameToDbName(this.entityName)).intern();
>>>      this.packageName =
>>> UtilXml.checkEmpty(entityElement.getAttribute("package-
>>> name")).intern();
>>>      this.defaultResourceName =
>>>
>>> UtilXml.checkEmpty(entityElement.getAttribute("default-resource-
>>> name")).intern();
>>>      this.dependentOn =
>>> UtilXml.checkEmpty(entityElement.getAttribute("dependent-
>>> on")).intern();
>>>      this.doLock =
>>> UtilXml.checkBoolean(entityElement.getAttribute("enable-lock"),  
>>> false);
>>>      this.noAutoStamp =
>>> UtilXml.checkBoolean(entityElement.getAttribute("no-auto-stamp"),  
>>> false);
>>>      this.neverCache =
>>> UtilXml.checkBoolean(entityElement.getAttribute("never-cache"),  
>>> false);
>>>      this.autoClearCache =
>>> UtilXml.checkBoolean(entityElement.getAttribute("auto-clear-cache"),
>>> true);
>>>
>>> Plus it sets sequenceBankSize.
>>> How many, if any, of these fields should be callable from "extend-
>>> entity"?
>>>
>>> -Al
>>>
>>> ---------- Forwarded message ----------
>>> From: Al Byers <[hidden email]>
>>> Date: Fri, Mar 13, 2009 at 1:10 AM
>>> Subject: Why "never-cache" on OrderHeader and OrderItem?
>>> To: [hidden email]
>>>
>>>
>>> What is the general reason for turning cache off?
>>>
>>> Why for OrderHeader and OrderItem, in particular?
>>>
>>> Can caching be turned on via "extend-entity"?
>>>
>>> thanks for any info.
>>>
>>> -Al
>>>
>>
>>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
[snip]

>> By default entities are cached.
>
> Actually by default all entities are "cachable", not "cached". That is
> up to the code.
>
>> The default in the dtd means to allow
>> caching.  It takes an explicit change to disable the cache.  There
>> must have been some reason why this explicit cache disable was done.
>> Wouldn't it be useful if such a policy decision was documented, if the
>> reasons why were written down somewhere?
>
> Sounds good. Is that something you are saying you'd like to work on?

+1

I'm ready to help, as I always say an API (moreover more complex artifacts built under an API) wihout documentation loses most of
its interest and power for others (and even in some cases for the one who wrote it ;o)

Jacques
[snip]

[Jacques Le Roux]

I guess here is the matter I was asking for in my previous email. Someone just have to write something in wiki now, Adam ?

Jacques

From: "David E Jones" <[hidden email]>

>
> Interesting. Are you running into performance problems with that or  
> something?
>
> The reason I ask is because this doesn't seem to meet the criteria for  
> being a good use of a cache.
>
> Read versus write frequency: More reads than writes, but it's not  
> clear if it's enough for a +1 on this; usually for this to be an  
> effective plus you need a LOT more reads than writes (+1, possibly +0)
> Population size, consumers versus producers: not sure based on what  
> you write, but it sounds like they are fairly equal in size (+0,  
> possibly -1)
> Sensitivity to stale data: somewhat sensitive to stale data (-1)
>
> As to implementation details: While we could support overriding this  
> attribute in the extend-entity, you could also just patch the  
> entitymodel.xml file to modify that one line during your build  
> process, or however you are managing base ofbiz changes.
>
> Whether or not OrderHeader/Item are good choices for your application  
> is another question altogether, and one that to answer properly would  
> require a good deal more information, like ORM-style statements about  
> the information you need to keep track of and how it relates to other  
> information.
>
> Anyway, whatever the case, best of luck with it. This sounds like a  
> "gray area" scenario, and I guess if I were facing it I'd do some  
> performance testing to establish a baseline that shows the performance  
> problem, and then see if introducing the cache actually helps.  
> Actually, I guess if I were to decide on something like this the  
> possible stale cache issue would be a show-stopper.
>
> -David
>
>
> On Mar 19, 2009, at 3:59 PM, Al Byers wrote:
>
>> We are modeling the delivery of online exams using OrderHeader and
>> OrderItem. The client needs to check often to see if the statusId  
>> has been
>> changed by the supervisor.
>>
>> Would we be better off to create another entity, keyed by orderId and
>> orderItemSeqId, just for this purpose?
>>
>> -Al
>>
>> On Thu, Mar 19, 2009 at 2:24 PM, David E Jones
>> <[hidden email]>wrote:
>>
>>>
>>> Stepping back a little, why do you want to cache data from those  
>>> entities?
>>>
>>> -David
>>>
>>>
>>>
>>> On Mar 19, 2009, at 11:13 AM, Al Byers wrote:
>>>
>>> I am moving this post to dev because I see that "extend-entity"  
>>> does not
>>>> call populateBasicInfo in ModelEntity. I am guessing that there are
>>>> properties that you do not want overridden in extend-entity, but I  
>>>> would
>>>> like to override "never-cache".
>>>>
>>>> I see that there is a "setNeverCache", but I don't see when it  
>>>> would be
>>>> called - when are instances of ModelEntity created - couldn't  
>>>> there be
>>>> many
>>>> of them? When would I apply "setNeverCache"?
>>>>
>>>> Here is what populateBasicInfo sets:
>>>>      this.entityName =
>>>> UtilXml.checkEmpty(entityElement.getAttribute("entity-
>>>> name")).intern();
>>>>      this.tableName =
>>>> UtilXml.checkEmpty(entityElement.getAttribute("table-name"),
>>>> ModelUtil.javaNameToDbName(this.entityName)).intern();
>>>>      this.packageName =
>>>> UtilXml.checkEmpty(entityElement.getAttribute("package-
>>>> name")).intern();
>>>>      this.defaultResourceName =
>>>>
>>>> UtilXml.checkEmpty(entityElement.getAttribute("default-resource-
>>>> name")).intern();
>>>>      this.dependentOn =
>>>> UtilXml.checkEmpty(entityElement.getAttribute("dependent-
>>>> on")).intern();
>>>>      this.doLock =
>>>> UtilXml.checkBoolean(entityElement.getAttribute("enable-lock"),  
>>>> false);
>>>>      this.noAutoStamp =
>>>> UtilXml.checkBoolean(entityElement.getAttribute("no-auto-stamp"),  
>>>> false);
>>>>      this.neverCache =
>>>> UtilXml.checkBoolean(entityElement.getAttribute("never-cache"),  
>>>> false);
>>>>      this.autoClearCache =
>>>> UtilXml.checkBoolean(entityElement.getAttribute("auto-clear-cache"),
>>>> true);
>>>>
>>>> Plus it sets sequenceBankSize.
>>>> How many, if any, of these fields should be callable from "extend-
>>>> entity"?
>>>>
>>>> -Al
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Al Byers <[hidden email]>
>>>> Date: Fri, Mar 13, 2009 at 1:10 AM
>>>> Subject: Why "never-cache" on OrderHeader and OrderItem?
>>>> To: [hidden email]
>>>>
>>>>
>>>> What is the general reason for turning cache off?
>>>>
>>>> Why for OrderHeader and OrderItem, in particular?
>>>>
>>>> Can caching be turned on via "extend-entity"?
>>>>
>>>> thanks for any info.
>>>>
>>>> -Al
>>>>
>>>
>>>
>