The product isn't using cStringIO. I didn't even know it existed until now ;) I stepped through the code, and in lib/python/ZODB/Connection.py in the commit() function, when it gets to the line dump(state) on line 347 where state is (apparently) all the correct information for my object, it gets the UnpickleableError. I noticed in the Collector that bug #383 was about Unpickleable errors with SQL methods. The object that's trying to get pickled in this case contains SQL methods. Granted, bug 383 was from around this time last year, but it's the best lead I've got so far. I don't use cStringIO anywhere in my product.
Well.... since my product *does* use the SQL class, and the SQL class uses the DA class, and the DA class uses cStringIO, I guess *technically* I am using it. We create SQL methods then store them as properties of the class. This may be what it's choking on.
It shouldn't be - SQLMethods don't ever actually assign a StringIO to anything but transient variables. The Results object returned from a query could in some cases wrap a StringIO instance - you don't do anything in your product where Results objects would be stored as object attributes do you? If this were a problem common to all SQLMethod objects then I would expect people to be seeing this error all over the place. Is anyone else seeing this? If you're not storing Results anywhere, it would be helpful to see the str() of the 'state' being dumped in commit() - also to know what database adapter/version you are using... Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com
Brian Lloyd wrote:
Well.... since my product *does* use the SQL class, and the SQL class uses the DA class, and the DA class uses cStringIO, I guess *technically* I am using it. We create SQL methods then store them as properties of the class. This may be what it's choking on.
It shouldn't be - SQLMethods don't ever actually assign a StringIO to anything but transient variables. The Results object returned from a query could in some cases wrap a StringIO instance - you don't do anything in your product where Results objects would be stored as object attributes do you? If this were a problem common to all SQLMethod objects then I would expect people to be seeing this error all over the place. Is anyone else seeing this?
No, although we do have a class that we use to wrap around some of the results that we sometimes return instead of the results themselves. I'll try taking that out and see if that's the problem.
If you're not storing Results anywhere, it would be helpful to see the str() of the 'state' being dumped in commit() - also to know what database adapter/version you are using...
Here are the contents of 'state': {'testID': <sqlCatalog instance at 860e7e0>, '_objects': ({'meta_type': 'SQL Product Catalog', 'id': 'testID'},)} We're using ZMySQLDA v1.1.3. -- Nick Garcia | ngarcia@codeit.com CodeIt Computing | http://codeit.com
participants (2)
-
Brian Lloyd -
Nick Garcia