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 making a single call to create() with all the required schema files at one go. Your prototype caching code is still in place, but currently only gets involved when create() is called with the old-style signature. I've checked that it still works in that case. Did you have a design in mind for how to update the table key to represent a set of schema files? I know this isn't a complete solution. Adding the schemas all at once will be useful, but I think there are still cases where addTypes() will be needed later. When that happens, I would like to be able to clone the DataFactory, that is, to make a copy without having to re- read the schema files, so that the additional types can be added and the original factory kept unchanged. But to do this would require a clone function that doesn't currently exist in the underlying Tuscany library. On Feb 27, 3:54 pm, "Matthew Peters" <[EMAIL PROTECTED]> wrote: > > Given how infrequently a given WSDL or schema file changes, it makes > no sense to pound away on it building the SDO model from it on every > request. We ought to cache the result of doing that: caching either > the SDO model or the data factory that contains that model. > > There are two approaches we could take: > 1. We could try to keep the interface unchanged, so all PHP code > continues to use just SDO_DAS_XML::create() and addTypes() ... > 2. We could put in some explicit caching that is visible at the PHP > level and is controlled by the SCA for PHP code or even the > application code somehow > > There are, independently, a couple of possibilities for where and what > we cache. Two options seem to be: > A. we could serialise the SDO model out to a file and read it back > in when needed ... > B. we could hold on to the data factory within memory, within the > sdo_php extension. > > We examined option A, write the XML DAS to a file. What we found is > that there is logic in the XML DAS to cache the model to a file > already, but it caches as schema, so reading it back in just gets us > back into loading schema again. So, we would need to come up with a > format - binary or human-readable - that is quicker to re-read. We > imagine by the way that anything cached in this way does not have to > last very long. We would not want to get into the situation of trying > to have file formats that were compatible across different releases of > SDO, or between different platforms, or anything fancy. > > So, we have concluded that the simplest thing to do is probably to > cache in memory, option B. > > Now look at the options 1. vs 2. i.e the interface. The ideal is > probably to keep the interface unchanged, but in the meantime we might > want to do something quicker to implement as a stop-gap, even if it > puts a bit of responsibility into the SCA code. > > The thing that worries me about option 1. comes about because we have > addTypes(). If you do create(), followed by a string of addTypes(), at > what point do you consider the data factory/model finished? And then > they come back issuing the same string of create() and addTypes() > (hence wanting the exact same model), how do you spot that and use the > cached one? It seems to me that that needs a solution. Perhaps allow > create() to take an array of types, and make that array the the key to > the cached DAS? > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
