On Oct 11, 2009, at 11:13 AM, Manlio Perillo wrote:
> > My use case is quite simple; I always call .fetchall from a > ResulProxy, > so all data is in memory. > > I don't see any reasons why a RowProxy should not be pickleable in > this > case. > I have tried with SQLAlchemy 0.4.2p3 (the version I'm using in > production, and I get this traceback: > http://paste.pocoo.org/show/144372/ > > I have to say that I don't understand the error. its probably working its way up to the ResultProxy and all the things associated with it that are not pickleable, including the DBAPI cursor and the live connection. __getstate__ is not implemented so there are no limits to the pickle traversal. > >> [...] > > If there is no simple method to pickle a RowProxy, then I should > create > a custom driver where the BufferedColumnRow is used. BufferedColumnRow is also not picklable. The reference to the parent ResultProxy is still required which itself is not picklable. To really do this would require building a "mock" ResultProxy that gets attached to the unpickled RowProxy as the "parent", which provides the services that RowProxy is looking for, except the "parent" would just hold onto the grid of fully processed results. The row also supports targeting of its contents using Column objects, that feature would likely not be able to follow the identical usage contract that it has now. In any case this feature request would only be for 0.6. It also would be ludicrous to not also make pickleable the NamedTuple that comes back from Query(), which is unpicklable for entirely different reasons. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
