On Nov 15, 2007 3:13 PM, Gary Wilson <[EMAIL PROTECTED]> wrote: > > Collin Grady wrote: > > Are you seeing this behavior in admin? If so, I believe that is what is > > actually at fault, since it hard-sets m2ms, which would clear anything > > set in save(). > > I know Russ didn't take much of a liking to this idea last time I mentioned > it, but...
Just to reiterate what I said last time: Firstly, this would be _huge_ backwards incompatibility. If this change were to be made, finding and fixing models that relied upon the old behaviour would be a non-trivial exercise. In the absence of a _very_ compelling reason to make this change, you'll find me coming down -1 for this reason alone. Secondly, although an m2m field is defined on a single model, isn't associated with a single model. It's associated with _two_ models. To me, this means that putting the save on the relation (i.e., when you assign the m2m attribute) rather than associating it with a particular model makes conceptual sense. If we were to move the m2m saving as part of the model save, you need to know which side of the m2m the field was defined upon, which is unwieldy because it presupposed knowledge of the model design. Alternatively, if you put the m2m saving on the save method of both models, there would be two different ways to effect the same database change. Thirdly, I'm not completely convinced that your proposed scheme won't end up with similar (or possibly even 0worse) race conditions. At present, the rules are simple - save all your models, then add all your m2m relations. If we moved saving m2m to the instances, then when you save instance X, you need to be sure that all the instances with which X has an m2m relation are also saved (say, instance Y). If instance Y then has an m2m relation back onto X through some other attribute, you've got yourself tied in a knot. > As far as AutomaticManipulator.save(), it appears that there is follow and > edit_inline logic mixed in with the manytomany saving. Does anyone who is > more familiar with newforms-admin know if the situation would be any better > there? I certainly hope so - that's why we're building newforms :-) Broadly, though, newforms has much better separation of concerns when it comes to dealing with inline objects; each inline object is handled as a discrete form, tied up in a formset wrapper that knows which object the formset is related to. This means there are a lot more (and a lot better isolated) points for customization of save behaviour. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" 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/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
