> > 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        [EMAIL PROTECTED]
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to