Heiko Wundram wrote: > Am 15.01.2012 13:22, schrieb Peter Otten:
>> I'm curious: did you actually get false cache hits in a suds cache >> or just slower responses? > It broke the application using suds, not due to false cache hits, but > due to not getting a cache hit anymore at all. > so basically I worked around > the problem by creating an appropriate cache entry with the appropriate > name based on hash() using a local copy of xml.dtd I had around. This > took place on a development machine (32-bit), and when migrating the > application to a production machine (64-bit), the cache file wasn't used > anymore (due to the hash not being stable). Thanks for the explanation. > if the hash() output is changed. Additionally, if hash() isn't stable > between runs (the randomized hash() solution which is preferred, and > would also be my preference), suds caching becomes completely useless. > And for the results, see above. I've taken a quick look into the suds source; the good news is that you have to change a single method, reader.Reader.mangle(), to fix the problem with hash stability. However, I didn't see any code to deal with hash collisions at all. -- http://mail.python.org/mailman/listinfo/python-list
