I wonder what happened to the post I just sent
... forget the words I said last time, since Caroline said it had to
be an object not an array I proposed the following interface:
$key = // calculate this in some way based on the xsd or xsds to be
used.
if (SDO::cache-containsKey($key)) {
Graham Charters wrote:
One *real* comment: I think we should be getting into the habit of
using magic method-style things which appear on the SDO interface
(and also our proxy interfaces) to reduce the risk of clashes with the
business interfaces (in this case the properties of an SDO, and
On 5 Jun, 10:36, Caroline Maynard [EMAIL PROTECTED] wrote:
Graham Charters wrote:
One *real* comment: I think we should be getting into the habit of
using magic method-style things which appear on the SDO interface
(and also our proxy interfaces) to reduce the risk of clashes with the
Graham Charters wrote:
I mentioned the proxies as one of the two areas where we need to keep
the interface clean (the other was SDO). I mentioned SDO because the
cache appears to be on the SDO interface in Matthew's example code
(unless I've misunderstood).
No, you haven't misunderstood, I
Matthew, one more thing I'd like to add to this discussion, which struck
me as I was listening to Brian Shire's excellent presentation at php|tek
(http://tekrat.com/wp/talks/phptek2007/[EMAIL PROTECTED]). There are
already several caching solutions for php, in particular APC, also
memcache
Graham Charters wrote:
Ah, I think I have misunderstood, and it's the subtle (at least to my
brain) distinction between SDO and SDO_DataObject. What do you mean
by adding a property to the extension? I'm not aware of an
interface we expose called SDO so jumped to the conclusion that this
Bad form to reply to my own post, but just after I sent it I saw this
thread in the internals mailing list:
http://thread.gmane.org/gmane.comp.php.devel/43094
so we shouldn't use APC to cache SCA objects without giving some thought
to how they get serialized. That's probably not too
I just checked in to DUNLIN a temporary change so that the ebaysoap
binding uses the caching of the data factory. Specifically, what I did
was:
1. enable the caching in the sdo extension when the special two-
argument version of SDO_DAS_XML::create is used
2. make the table of cached data
Sorry all that I am really late in this conversation (only a few weeks
behind). Been meaning to respond but always get distracted by
something (think I got ADD or something) :/.
I think I had mentioned this before but I really think there needs to
be 2 (at least) modes to this.
In my case, our
Yes, exactly right. The scope is intended to be module init to
shutdown, and across all callers. I don't really know how I could do
otherwise - a per-request cache would be throwing away all the
benefit.
Of course you have worried me now. If the keys are chosen poorly - for
example every call
Matthew,
I've made a change to the signature of SDO_DAS_XML::create(). Instead
of a single path to a schema file, this now takes an array of paths to
schema files. This is checked into the BUZZARD branch.
The idea here is that people can in most cases avoid the problem of
addTypes(), by instead
11 matches
Mail list logo
