narrow writes (as 3rd-party library)

[Jeremy Dunck]

I'm attempting to implement narrow writes (that is, writing only fields which have changed).

I would be able to do this as a 3rd-party Mixin library if some changes were made to Model.save_base.

  1)  returned whether the row was created or updated, e.g. if .save_base returned the `updated` value which it uses to send the .post_save signal.

  2) raise something finer-grained than DatabaseError when force_update is used (so that I could then try a (wide) insert-or-update.  The new exception could inherit from DatabaseError for backwards-compat.

Any objections to me making these changes?

[Loic Bistuer]

On Jul 17, 2014, at 5:16 AM, Jeremy Dunck <jdu...@gmail.com> wrote:

> 1) returned whether the row was created or updated, e.g. if .save_base returned the `updated` value which it uses to send the .post_save signal.
> 2) raise something finer-grained than DatabaseError when force_update is used (so that I could then try a (wide) insert-or-update. The new exception could inherit from DatabaseError for backwards-compat.
>
> Any objections to me making these changes?

Both make sense to me (+1).

--
Loic

[Russell Keith-Magee]

Broadly, sounds fine to me.

The only thing I would flag is that DatabaseError (and it's subclasses) are specified by PEP249:

http://legacy.python.org/dev/peps/pep-0249/#exceptions

and we wrap those exceptions and surface them to the user essentially verbatim. If we're introducing a new exception, that would be a subtle change in the contract - we're introducing something that isn't par of PEP249. 

To be clear - I don't have a specific concern or opinion here; I'm just flagging that if we're changing the general contract around database exceptions, it's worth some extra thought to make sure we're not missing anything.

Russ %-)