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
<[email protected]>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 <[email protected]>
Date: Fri, Mar 13, 2009 at 1:10 AM
Subject: Why "never-cache" on OrderHeader and OrderItem?
To: [email protected]
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
