Tefnet Developers wrote: > > Dnia 2009-11-02, pon o godzinie 11:05 -0500, Michael Bayer pisze: > >> flush what you need first. then do things that are not compatible with >> autoflush. > > The point is that I am developing a layer which attempts to hide all > sqlalchemy/relational details and provide a clean and consitent API to > effectively build/manage persistent python data structures. Enforcing > the user (developer) to call flush() "in case" seems wrong to me.
Providing AttributeExtension hooks to end users who can then write custom code without any attention to object/session state is never guaranteed to work completely. For example, here is a simple test which until recent versions silently fails: http://www.sqlalchemy.org/trac/attachment/ticket/1526/validator_bug.py the bug is now "fixed" in that an assertion is raised for errors of that particular type by detecting activity on the collection. I don't know offhand what other kinds of reentrant/state issues can be introduced by allowing any sort of code in an extension, as AttributeExtensions were never intended to provide full ORM access within. In this case you're requesting a change be back-ported to a stable API (0.5) to suit one such kind of error you've discovered. Why isn't it an option, when granting users access to AttributeExtension, that you flush() their session first ? you would then disable autoflush temporarily at the Session level (just set the "autoflush" attribute on it). >> I would also need to document within another test how >> autoflush is being called from within modified_event(). > > I am kinda lost here - do you mean running queries in AttributeExtension > with autoflush=True resulting in flushes or something else? just to confirm, the issue here is modified_event() places the object in "dirty", naive attributeextension issues a query which then autoflushes the object, the object's state is not complete so the flush fails. if that's the case, a test of this nature is not super-critical. The patch is fine, but needs at least a few tests to lock it down, and I'm hesitant to backport to 0.5, for the reason that there can't be even subtle backwards-incompatible changes in an 0.5 maintenance release, even if they are improved behaviors, and I don't have the resources right now to pore over every possible case for this patch to ensure that's the case. Whereas releasing as 0.6beta allows hundreds of users to run the code in "test" mode for several weeks which would uncover any subtleties. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
