When evolving the caching, I left the intermediate caching in place so that when a top
level object needed to be rebuilt, it could potentially be done with some cached content
rather then downloading all of it. The intent was that if the wsdl Definitions object
graph expired in the cache, some/most of the raw xml files could be read from cache. That
said, in cases where wsdls are written as a web of many wsdl fragments which are imported
into each other and the top wsdl, this approach can be costly. Most wsdls are written
with a sane usage of import. Anyway, this needs to be optimized in 0.4.
Now, as for your circular wsdl import issue. I took great care in handling these cases in
the XSD package (for schemas). Import/Include scenarios can be extremely complex.
Especially when taking namespaces into account and reference resolution. I can apply the
same load/merge algorithm to the wsdl loading but it will take some effort. The reason,
the wsdl loading is simple in suds is that wsdl import should be linear. Except for
sadistic pleasure, I can't think of a valid reason to have mutual imports in wsdls. I
don't mean to imply that your problem isn't valid ;) Or, that I don't intend
to help.
Just giving some background.
I guess what I'm saying is that mutual imports in wsdls is an edge case that I am glad
to
address but has not been a priority. It will require (as you pointed out) a significant
overhaul of the way wsdls are loaded & merged. if done properly, I think the caching
will
not interfere.
I'll have to see if I can scope this for 0.4. I'll need access to a good test
case like
yours. Sorry that I don't know off the top of my head: Do you have a ticket on this?
I
see ticket #255. This related to you?
On 02/25/2010 08:00 AM, Rod Montgomery wrote:
Suds is caching each WSDL file at least twice, in file reader.py:
Class DocumentReader caches the raw sax.parse tree
Class DefinitionsReader caches the class Definitions (from file wsdl.py) data structure.
If there are imports among WSDL files, even more copies get cached.
For example, A imports B imports C -- then the cache will contain
raw sax.parse for C
Definitions for C
raw sax.parse for B
Definitions for B with C imported and resolved
raw sax.parse for A
Definitions for A with B and C imported and resolved
If I eliminate the caching of the Definitions below the top level, so that only the raw
sax.parse trees get cached, what will
break?
The reason I want to do this is to simplify the code, to make it easier to modify it to
handle WSDL files that have circular
importing relationships, such as A imports B and B imports A.
Assuming none of the WSDL files changes, the most important thing to cache is the
Definitions structure for the top-level
WSDL files. That is what the Client class needs to create a new Client instance for a
particular service.
The only time caching the Definitions structures for WSDL files below top level improves
performance is when the same
lower-level WSDL file gets imported by several top-level WSDL files.
If one of the WSDL files changes, you really need to invalidate the whole cache anyway,
or you'll risk using stale copies of
Definitions structures for WSDL files that import the changed file.
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds