Re: Models created from querysets aren't constructed with constructor

On Mon, 2008-04-28 at 15:30 -0500, Martin Diers wrote: > I could be wrong, but I believe that this is because a Model is not > derived from the default __metaclass__, but is generated by a separate > class factory which overrides the default behavior. No, that has nothing to do with it. It's

Re: Models created from querysets aren't constructed with constructor

On Tue, 2008-04-29 at 00:03 +0400, Ivan Sagalaev wrote: > Hello everyone (and especially Malcolm :-) ) > > I've just hit a wall with a behavior that I find a bit strange. When a > model is instantiated from a queryset result it's not created with it's > own constructor but instead uses Model.f

Re: Aggregate Support to the ORM

On Mon, Apr 28, 2008 at 2:10 PM, Nicolas E. Lara G. <[EMAIL PROTECTED]> wrote: > I didn't understand your point here. When is the data incomplete? An example would be grouping people by age and averaging income, what should the values of the name field be? None might make sense at first, as Honz

Patch on #6776

I have attached a patch to #6776 [1] that solves the AlreadyRegistered [2] problem according to what seemed to be the consensus. Which basically is to throw the AlreadyRegistered exception on registration of a different ModelAdmin that may have been previously registered with a model. I am

Re: Aggregate Support to the ORM

Hi Justin, > I really like Honza's idea of an AggregateModel, at least for cases where > there's a 1-1 correspondence between results and actual instances, so that > the model will still behave as expected. To keep from cluttering the model's > attributes, aggregate values could be put into anoth

Re: Models created from querysets aren't constructed with constructor

Martin Diers wrote: > I could be wrong, but I believe that this is because a Model is not > derived from the default __metaclass__, but is generated by a separate > class factory which overrides the default behavior. Yes, but my question is not how it's happening but what's the reason of it.

Re: Models created from querysets aren't constructed with constructor

I could be wrong, but I believe that this is because a Model is not derived from the default __metaclass__, but is generated by a separate class factory which overrides the default behavior. On Apr 28, 2008, at 3:03 PM, Ivan Sagalaev wrote: > > Hello everyone (and especially Malcolm :-) ) >

Re: Models created from querysets aren't constructed with constructor

On Mon, Apr 28, 2008 at 4:03 PM, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I've just hit a wall with a behavior that I find a bit strange. When a > model is instantiated from a queryset result it's not created with it's > own constructor but instead uses Model.from_sequence that does creates >

Models created from querysets aren't constructed with constructor

Hello everyone (and especially Malcolm :-) ) I've just hit a wall with a behavior that I find a bit strange. When a model is instantiated from a queryset result it's not created with it's own constructor but instead uses Model.from_sequence that does creates an Empty() instance and then change

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

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

Re: Aggregate Support to the ORM

Hey everyone, Good to see this has come up again. Congrats on getting the GSoC selection Nicolas. The previous thread[1] has a lot of good discussion in it if anyone here wasn't following that. Obviously, I prefer the expression object API. I've actually been using it a bit in an order processing

Re: login decorator

On Mon, Apr 28, 2008 at 2:50 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 28, 2008 at 1:49 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 28, 2008 at 2:41 PM, garrettjohnson <[EMAIL PROTECTED]> > wrote: > > > > > > > > @login_required, redirects to '/accounts/login'

Re: login decorator

On Mon, Apr 28, 2008 at 1:49 PM, Karen Tracey <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 2:41 PM, garrettjohnson <[EMAIL PROTECTED]> wrote: > > > > > @login_required, redirects to '/accounts/login' ... > > See http://www.djangoproject.com/documentation/settings/#login-url > > But you

Re: login decorator

On Mon, Apr 28, 2008 at 2:41 PM, garrettjohnson <[EMAIL PROTECTED]> wrote: > > @login_required, redirects to '/accounts/login' > > I do not have my registration app configured to point to that url > > How would you overide this default ? > > (i want my redirected to '/Login') > See http:/

login decorator

@login_required, redirects to '/accounts/login' I do not have my registration app configured to point to that url How would you overide this default ? (i want my redirected to '/Login') --~--~-~--~~~---~--~~ You received this message because you are subsc

Re: Queryset-refactor branch has been merged into trunk

Malcolm Tredinnick wrote: > I merged queryset-refactor into trunk just now. This was changeset > r7477. Thanks for all of your effort on this, Malcolm. Malcolm's Amazon Wishlist: http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1VB5A16R2KV0T

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

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

Re: API question for model saving

> 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.

Re: API question for model saving

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

Re: API question for model saving

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. >>>

Re: API question for model saving

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

Re: API question for model saving

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(),

Re: API question for model saving

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

Re: API question for model saving

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: > >>

Re: API question for model saving

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,

Re: API question for model saving

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

Re: API question for model saving

> 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

Re: API question for model saving

> (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