On Apr 22, 2:42 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Yes, it would work. Why is it necessary to introduce the complexity (and
> risk of screwing it up), though? We have the default attribute on models
> for this type of thing. You're really leaking abstractions here.
I'm not saying
On Sun, 2007-04-22 at 06:56 +, Collin Grady wrote:
> On Apr 21, 9:53 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > Your database may still have a serial value
> > on that field, for example, or there may be a trigger that does the
> > value computation. Both of these are a little unr
On Apr 21, 9:53 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Your database may still have a serial value
> on that field, for example, or there may be a trigger that does the
> value computation. Both of these are a little unrealistic, but not out
> of the bounds of possibility (because peo
On Sun, 2007-04-22 at 04:25 +, Collin Grady wrote:
> I've been looking at save() recently for work on
> http://code.djangoproject.com/ticket/4102
> and I noticed what seems to be a problem in the primary key logic, but
> I'm not entirely sure :)
>
> In the block for saving an existing model
I've been looking at save() recently for work on
http://code.djangoproject.com/ticket/4102
and I noticed what seems to be a problem in the primary key logic, but
I'm not entirely sure :)
In the block for saving an existing model object, it uses the non_pks
list which is generated by testing for
