Let's not quote me if you don't understand what I'm saying.
The patch we applied at Curse did the following (and solved some extra
queries):
- Added an _is_stored attribute on instances, default value was None
- _is_stored became True upon an instance retrieval via a QuerySet
- _is_stored became False upon using create()
- If _is_stored was True it always performed an update
- If _is_stored was False it always performed an insert
- if _is_stored was not set it'd use the default behavior.
This may not directly solve the problems that are being referred to, but it
was a bug fix none the less, and I believe it is relative to the issue at
hand.
On Sun, May 4, 2008 at 6:06 PM, Benjamin Slavin <[EMAIL PROTECTED]>
wrote:
>
> On Sun, May 4, 2008 at 7:02 PM, James Bennett <[EMAIL PROTECTED]>
> wrote:
> > The first is to look at the update() method that already exists on
> every
> > QuerySet and every default manager: this method *already* does one of
> > the things we want, namely force an UPDATE query to run. So, without
> > any changes whatsoever, a proposed API of, say::
> >
> > e = Employee(drone_id=1234567)
> > e.salary = 1000000000
> > e.save(force_update=True)
> >
> > Can become::
> >
> > Employee.objects.filter(drone_id=1234567).update(salary=1000000000)
>
> This is an interesting attempt to change the underlying debate, but
> I'm -1 for the reasons listed below.
>
>
> > Now, the complaint people will have with this is that you can
> > accidentally leave off the filtering, or do it wrong, and make
> > everybody in the company a billionaire.
>
> Actually, my first thought is one of DRY, but here are the concerns
> that jump to mind in no particular order:
>
> 1) Using the PK filter in every update is not respecting DRY. (I also
> have scary visions of `type(e).objects.filter(**{e._meta.pk.name:
> e.pk})` ending up in code designed to handle multiple models.)
>
> 2) The accidental omission of filter has highly destructive
> side-effects. Sure, this is programmer error, but need we make it so
> easy to shoot oneself in the foot?
>
> 3) The update mechanism is no longer parallel to the API for other
> per-instance persistence operations.
>
> 4) This breaks the way in which custom DB fields must be handled. This
> means that custom DB fields are no longer opaque to the programmer,
> and implementations of update are tightly coupled to the specific
> implementation of the field. [0]
>
> 5) This doesn't provide a consistent way to implement pre-save
> functionality on the model (I mean the things that are traditionally
> done by overriding `save`, but #4 above might be an extension of
> this).
>
>
> > That deals with one of the three cases (force UPDATE), which means
> > that save() itself only needs to deal with two cases: "force INSERT"
> > and "I don't care".
> >
> > From there, save() simply sprouts a "force_insert" kwarg, defaulting
> > to False, and you handle that when you care about it.
>
> I like the line of thought that lead to this, but find myself in the
> insert/create and update camp. Internally, we've been using some
> monkeypatching to add .insert and .update methods to all models (we
> needed this functionality on models that were in contrib).
>
>
> > Also, the bikeshed should be blue.
>
> Market research suggests that it should be a garish orange.
>
>
> Regards,
> - Ben
>
>
> [0] A quick peek at the internals of UpdateQuery makes me think this
> is correct, though Malcolm may know better than me.
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
