On Dec 20, 2007, at 1:04 PM, Anton V. Belyaev wrote:
> So, to be cached, an object should fetch all its deferred columns (if > any) and provide all of them at __getstate__. Right? that would work. > And if an instance from cache has nothing for one of its deferred > column values, then referencing these properties after merge wont load > them from DB, but just fail? as far as merge failing, I need to see what the exact mechanics of that error message are. For a polymorphic "deferred" in particular, its a major chunk of an object's state that is deferred, i.e. everything corresponding to the joined tables, and the callables are currently established at the per-instance level. So it may be necessary now for merge to still "fail" if unloadable deferreds are detected, although we can and should provide a nicer error message. Some longer term solutions to the "pickled" issue include trying to be more aggressive about placing class-level attribute loaders which dont need to be serialized, placing "hints" in the _state which could help the _state to reconstruct the per-instance deferred callables, or we might even be able to get the _state to call deferreds during serialization without the need for an explicit __getstate__, but then you are caching all that additional state. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
