On 3 mars 2013, at 17:09, Christophe Pettus <[email protected]> wrote:
> Right now, the only real example I've heard (there might be more is): > > 1. The ORM generates multiple updating operations for a single API-level > operation. > 2. The developer did nothing to manage their transaction model (no decorator, > no middleware), but, > 3. Is relying on Django to provide a transaction in this case. > > That situation does exist, but it does seem pretty edge-case-y. Does it > exist in any case besides model inheritance? If not, could we have the ORM > wrap those operations in a transaction in that particular case? Yes, I plan to ensure that all public ORM APIs are atomic. I'm not sure that they currently are; under autocommit, they probably aren't. I will make a proposal to improve transaction management right after I've finished implementing autocommit. In practice, the solution is probably called @xact. Applying it to each public ORM function should do the trick. Therefore, I'd like to ask your permission to copy it in Django. Technically speaking, this means relicensing it from PostgreSQL to BSD. Thanks, -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
