[Patch] Marking instances as db-stored via is_stored

[David Cramer <dcramer@…>]

This patch adds a flag to instance called 'is_stored'. By default it is set to None. When a DB instance is available in the database it is True, and when its removed it is False.

This corrects the need for Django guessing based on the PK value if it needs to try to do an update or insert, and should throw exceptions if you try to do an insert (.create) when a matching pk exists.

[David Cramer <dcramer@…>]

Fixed diff's, and changed is_stored to _is_stored.

[anonymous]

For future reference - use one patch, not two, and you won't win any friends without tests :-)

[Adrian Holovaty]

I like this a lot -- it's a smart optimization.

[Adrian Holovaty]

Hmm, I just realized there's a wide-open race condition here -- if an instance is marked as is_stored, then is deleted by another process, the save() method will be fooled into doing an UPDATE, and no records will be updated.

[David Cramer]

Design decision would be really good now. This isn't a feature, its a bug fix :)

[Johannes Dollinger]

-1

You would also have to track primary key changes to clear _is_stored, which doesn't seem worth it given that you never know whether the object is still in the db (see adrian's comment).

​Explicit update/insert support would be more useful to optimize/prevent bugs where it is required.

[David Cramer]

Even if the primary key is changed it doesn't change the fact that it's stored. Are you saying that when you change the primary key of a row it should create a new row? (Thinking about it, I'd bet Django doesn't handle this, but it should).

[Johannes Dollinger]

Replying to dcramer:

Even if the primary key is changed it doesn't change the fact that it's stored. Are you saying that when you change the primary key of a row it should create a new row? (Thinking about it, I'd bet Django doesn't handle this, but it should).

No, django doesn't handle changing pks via .save() - and it would be quite painful: you had to update all related objects as well. IMO, changing primary keys is mostly unnecessary. So yes, I'd say creating a new row (or updating an existent row) is the right thing to do when you change the pk.

[Malcolm Tredinnick]

This seems to be solved via the addition of force_update and force_insert. That saves the guessing because you already know how you got the object.