I'd prefer multiple methods (save(), insert(), update()) to make
subclassing easier. If that's not an option, I'd suggest
Model.save(allow_update=True, allow_insert=True)
Then False,False would obviously be a no-op.
___
Johannes
--~--~-~--~~~---~--~~
You received
Here is the patch i was talking about:
http://code.djangoproject.com/ticket/5309
On Apr 28, 5:02 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote:
> > > For this particular case it saves a whole line. One concern I have is
> > > that if th
Let me also bring up once again, that this is what all the other major DB
layers that I've looked at do. So it doesn't seem like it's a bad solution
at all.
On Sun, May 4, 2008 at 11:11 PM, James Bennett <[EMAIL PROTECTED]>
wrote:
>
> On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED
On Mon, May 5, 2008 at 1:00 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> 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.
I never said it wasn't a *possible* solution, I just said it wa
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
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
> a
OK, so, we appear to have two camps:
1. People who think this should be handled by introducing one or more
new methods to allow easy differentiation of the cases.
2. People who think this should be handled by adding new keyword
arguments to save().
And, techncially, a third camp consistin
Are you talking about cloning objects that exist in the database? To where
you'd pull it out, unset the ID and then resave it?
On Thu, May 1, 2008 at 8:01 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On Thu, May 1, 2008 at 10:49 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> > On Thu, May 1, 20
On Thu, May 1, 2008 at 10:49 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > I'm still not quite sure why we need any additional methods, or flags, or
> anything. Can someone explain to me where the underlying API is havi
On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> I'm still not quite sure why we need any additional methods, or flags, or
> anything. Can someone explain to me where the underlying API is having
> issues?
Malcolm's initial note creating this thread described an example
I'm still not quite sure why we need any additional methods, or flags, or
anything. Can someone explain to me where the underlying API is having
issues?
On Thu, May 1, 2008 at 2:24 AM, Tai Lee <[EMAIL PROTECTED]> wrote:
>
> I'd vote for create() and update() methods which seem the least
> confusi
I'd vote for create() and update() methods which seem the least
confusing, but that doesn't seem very popular. If it has to be done
with arguments on save(), I'd say force_create=False,
force_update=False is the easiest to read and understand.
I'd prefer either of those options over a null/true/f
On Wed, Apr 30, 2008 at 5:22 PM, mrts <[EMAIL PROTECTED]> wrote:
> Looks like enums would be the most natural solution.
> As Python doesn't have enums, class attributes should be used
> (module level globals would clutter the namespace).
>
> Adding to Malcolm's initial proposal:
>
> # django/
Looks like enums would be the most natural solution.
As Python doesn't have enums, class attributes should be used
(module level globals would clutter the namespace).
Adding to Malcolm's initial proposal:
# django/db/models.py
class CreateStrategy:
MUST_CREATE = True
MUST_NOT_CREATE = Fals
Bikeshedding or not, what about something like
class _default_save_behaviour(object):
pass
...
def save(new_instance=_default_save_behaviour, ...):
if new_instance == _default_save_behaviour:
elif bool(new_instance):
else:
Regards
Niels
On Apr 28, 9:44 pm,
I don't really like the idea of having extra options on save (mostly
because I have a lot of save calls that already. Maybe I don't quite
see the point. I proposed an internal flag a while back which would
determine if something was actually being created or updated. I don't
think it was accepted
On Mon, Apr 28, 2008 at 12:11 PM, Mike Axiak <[EMAIL PROTECTED]> wrote:
> I would rather see two different parameters, e.g.::
>.save([force_update=True|False, force_create=True|False])
>
> That both default to False, and raise a ValueError when both are True.
>
I think this is by far the most
On Mon, Apr 28, 2008 at 3:09 PM, didier Belot <[EMAIL PROTECTED]> wrote:
>
> Mike Axiak a écrit :
> > [...]
> > Does it?
> >
> > myinstance.save(new_instance=True)
> >
> > Will this fail when it cannot create a new instance? Does it always
> > create a new instance?
> >
> > myinstance.save
On Apr 28, 3:11 pm, Mike Axiak <[EMAIL PROTECTED]> wrote:
> Of course that's just me.
I should also note that this is precisely the example used in FreeBSD
bikeshed argument [1]. I don't think it matters what parameters we use
that much, but I think it we can all agree that Django should support
i
On Apr 28, 3:06 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> thought the behavior of this option was clear from Malcolm's initial
> description. It does support the 1,2,3 you specify. Which alternative
> would you prefer?
Maybe it's just me, but I just don't like a parameter that seems
boolea
Mike Axiak a écrit :
> [...]
> Does it?
>
> myinstance.save(new_instance=True)
>
> Will this fail when it cannot create a new instance? Does it always
> create a new instance?
>
> myinstance.save(new_instance=False)
>
> Does this fail when it has to create a new instance?
>
> Which one of
On Mon, Apr 28, 2008 at 1:15 PM, Mike Axiak <[EMAIL PROTECTED]> wrote:
>
> On Apr 28, 1:10 pm, Martin Diers <[EMAIL PROTECTED]> wrote:
> > [...]
> >
> > new_instance = True / False
> >
> > is the best solution. It solves the readability test, keeps backward
> > compatibility, and prevents needless
On Apr 28, 1:10 pm, Martin Diers <[EMAIL PROTECTED]> wrote:
> [...]
>
> new_instance = True / False
>
> is the best solution. It solves the readability test, keeps backward
> compatibility, and prevents needless ambiguity which would ultimately
> lead to a dead function.
Does it?
myinsta
On Apr 27, 2008, at 7:44 PM, Karen Tracey wrote:
> On Sun, Apr 27, 2008 at 7:53 PM, Malcolm Tredinnick <[EMAIL PROTECTED]
> > wrote:
> [snipped problem description]
>
> (1) Model.save(must_create=None) where "must_create" is True (must
> create), False (must not create) or None (try an update; if
On Mon, 2008-04-28 at 13:49 +0200, David Danier wrote:
> > For this particular case it saves a whole line. One concern I have is
> > that if there's more complex logic in your overridden save method, some
> > of it is going to be useful in both cases and now you have to create
> > extra sub-funct
> For this particular case it saves a whole line. One concern I have is
> that if there's more complex logic in your overridden save method, some
> of it is going to be useful in both cases and now you have to create
> extra sub-functions for the common bits and remember to call them both
> times.
Malcolm Tredinnick wrote:
> Hey David,
>
> On Mon, 2008-04-28 at 12:21 +0200, David Larlet wrote:
> [...]
>
>> def save(self):
>> if not self.id:
>> self.some_date = datetime.now()
>> super(Model, self).save()
>>
>> to:
>>
>> def create(se
David Larlet wrote:
> Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>
>>> Sometimes when calling save(), we know (for business reasons) that it
>>> must create a new object or raise an error. Similarly, in other
>>> cases,
>>> it either must update an existing object or raise an error.
>>>
Hey David,
On Mon, 2008-04-28 at 12:21 +0200, David Larlet wrote:
[...]
> def save(self):
> if not self.id:
> self.some_date = datetime.now()
> super(Model, self).save()
>
> to:
>
> def create(self):
> self.some_date = datetime
On Sun, 2008-04-27 at 20:18 -0700, Ken Arnold wrote:
> On Apr 27, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
> > On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> > > I'd like to point out that in #2705, the patch creators have put the
> > > API on the side of the get(),
Le 28 avr. 08 à 09:33, David Danier a écrit :
>
>> Sometimes when calling save(), we know (for business reasons) that it
>> must create a new object or raise an error. Similarly, in other
>> cases,
>> it either must update an existing object or raise an error.
>
> I think discussion about this
On Mon, 2008-04-28 at 10:43 +0200, Johannes Beigel wrote:
> Am 28.04.2008 um 10:21 schrieb Malcolm Tredinnick:
> > On Mon, 2008-04-28 at 00:28 -0700, ludvig.ericson wrote:
> >>
> >> suppose:
> >>
> >>class MyModel(models.Model):
> >>def save(self):
> >>if not self.id:
> >>
Am 28.04.2008 um 10:21 schrieb Malcolm Tredinnick:
> On Mon, 2008-04-28 at 00:28 -0700, ludvig.ericson wrote:
>>
>> suppose:
>>
>>class MyModel(models.Model):
>>def save(self):
>>if not self.id:
>>self.some_date = datetime.now()
>>super(MyModel,
On Mon, 2008-04-28 at 00:28 -0700, ludvig.ericson wrote:
> > (1) Model.save(must_create=None) where "must_create" is True (must
> > create), False (must not create) or None (try an update; if that fails,
> > insert).
> >
> > (2) Model.save(method=DEFAULT) and this time "method" takes one of three
> Sometimes when calling save(), we know (for business reasons) that it
> must create a new object or raise an error. Similarly, in other cases,
> it either must update an existing object or raise an error.
I think discussion about this issue has been on this list before, last
time someone sugge
> (1) Model.save(must_create=None) where "must_create" is True (must
> create), False (must not create) or None (try an update; if that fails,
> insert).
>
> (2) Model.save(method=DEFAULT) and this time "method" takes one of three
> constant values (making up the names a bit): "DEFAULT", "MUST_CRE
On Sun, Apr 27, 2008 at 8:18 PM, Ken Arnold <[EMAIL PROTECTED]>
wrote:
> Possible fix: define more clearly whether Django thinks that the model
> is in the database or not. Currently that's (IIRC) based on whether
> the model has a primary key. But as Malcolm points out, a semantic
> primary key
On Apr 27, 8:58 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> > I'd like to point out that in #2705, the patch creators have put the
> > API on the side of the get(), as for_update(), so that the decision
> > about whether the sav
Le 27 avr. 08 à 22:37, Marty Alchin a écrit :
>
> On Sun, Apr 27, 2008 at 10:17 PM, Grégoire Cachet
> <[EMAIL PROTECTED]> wrote:
>> Why could you not include a parameter in the Meta class, like
>> no_update = True ?
>> By default, this parameter would be False.
>
> The problem is, in Malcolm's ex
On Sun, Apr 27, 2008 at 10:17 PM, Grégoire Cachet
<[EMAIL PROTECTED]> wrote:
> Why could you not include a parameter in the Meta class, like
> no_update = True ?
> By default, this parameter would be False.
The problem is, in Malcolm's example of an employee database, you
might well sometimes
Hey!
I have also been thinking to the problem lately.
If you're doing it because it's related to your business logic for a
specific model, I would rather see this feature in the model definition.
Why could you not include a parameter in the Meta class, like
no_update = True ?
By default, th
On Sun, 2008-04-27 at 20:14 -0500, Adrian Holovaty wrote:
> On Sun, Apr 27, 2008 at 6:53 PM, Malcolm Tredinnick
> <[EMAIL PROTECTED]> wrote:
> > Sometimes when calling save(), we know (for business reasons) that it
> > must create a new object or raise an error. Similarly, in other cases,
> >
On Sun, Apr 27, 2008 at 6:53 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> Sometimes when calling save(), we know (for business reasons) that it
> must create a new object or raise an error. Similarly, in other cases,
> it either must update an existing object or raise an error.
So I don
On Sun, 2008-04-27 at 20:59 -0400, Marty Alchin wrote:
> I'm a bit on the other side of the situation here. To me, save() seems
> adequately ambiguous, either inserting or updating depending on the
> situation. As an alternative, I'd think having separate methods, like
> create() and update() wou
I'm a bit on the other side of the situation here. To me, save() seems
adequately ambiguous, either inserting or updating depending on the
situation. As an alternative, I'd think having separate methods, like
create() and update() would make things clearer still.
In addition to avoiding the whole
On Sun, 2008-04-27 at 17:52 -0700, [EMAIL PROTECTED] wrote:
> I'd like to point out that in #2705, the patch creators have put the
> API on the side of the get(), as for_update(), so that the decision
> about whether the save should update or create is saved as state on
> the model instances them
I'd like to point out that in #2705, the patch creators have put the
API on the side of the get(), as for_update(), so that the decision
about whether the save should update or create is saved as state on
the model instances themselves. I don't really like that syntax, but
it is probably worth no
On Sun, Apr 27, 2008 at 7:53 PM, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
> [snipped problem description]
>
> (1) Model.save(must_create=None) where "must_create" is True (must
> create), False (must not create) or None (try an update; if that fails,
> insert).
>
>Pros: one parameter
One of the minor cleanup items I've got on my list now that the query
stuff is mostly done is fixing model saving so that in the odd cases
where finer control is necessary, we have it.
Sometimes when calling save(), we know (for business reasons) that it
must create a new object or raise an error
49 matches
Mail list logo
