Re: Shouldn't views.generic.create_update.lookup_object use the default manager instead of .objects?

It is indeed a bug. On Fri, Oct 7, 2011 at 10:19 AM, Guilherme Salgado <salg...@canonical.com> wrote: > Hi there, > > That function uses .objects on whatever model is passed to it by > update_object() (or delete_object()), and I can't think of a reason to > use that instead o

Shouldn't views.generic.create_update.lookup_object use the default manager instead of .objects?

Hi there, That function uses .objects on whatever model is passed to it by update_object() (or delete_object()), and I can't think of a reason to use that instead of the default manager (although my knowledge of Django internals is rather minimal), so I thought I'd ask here first before filing

Re: Default manager

On Tue, Dec 16, 2008 at 11:55 PM, Alex Rades wrote: > On Tue, Dec 16, 2008 at 5:49 PM, James Bennett wrote: >> >> On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato >> wrote: >>> I don't see any downside in this proposal. >> >>

Re: Default manager

On Tue, Dec 16, 2008 at 5:49 PM, James Bennett wrote: > > On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato > wrote: >> I don't see any downside in this proposal. > > His proposal seems to center around forcibly making "objects" *always* > be a

Re: Default manager

+1! > >> So, my proposal is to make the "objects" manager always present and >> accessible, and remove the _default_manager stuff. If you want to >> change the default manager, just override "objects". If you want to >> access the

Re: Default manager

On Tue, Dec 16, 2008 at 10:21 AM, Alberto Donato wrote: > I don't see any downside in this proposal. His proposal seems to center around forcibly making "objects" *always* be a manager returning an unfiltered QuerySet, so I'm not sure where it'd allow for that. And

Re: Default manager

emember to define the "objects" >> manager first, otherwise some parts of django (eg. admin) will not >> work. > > No, if you want to have every object viewable/editable in the admin > you have to either set up a default manager which makes all objects > available

Re: Default manager

g. admin) will not > work. No, if you want to have every object viewable/editable in the admin you have to either set up a default manager which makes all objects available, or you have to do some overriding in the ModelAdmin subclass to make sure it gets the QuerySet you want it to get. > I find thi

Re: Default manager

> So, my proposal is to make the "objects" manager always present and > accessible, and remove the _default_manager stuff. If you want to > change the default manager, just override "objects". If you want to > access the default man

Re: Default manager

I like the `objects` convention as well as explict default manager declarations. I proposed both in http://groups.google.at/group/django-developers/browse_thread/thread/3e1a668ac84328b6/ce36cbe46276d807 . Advertisement: My radical "solution" is to never modify t

Re: Default manager

greed about the 1.0 problem, but it might make sense to have a manager bound to objects if objects is not defined. Then objects could be used as a field or another manager as desired, but would bind to the default manager (wait for it)... by default. If you didn't want a manager defined, you could s

Re: Default manager

I observed was > internally consistent and made logical sense to me (if I recall correctly, > if something was excluded in the default manager, it didn't show up in the > change list, and an attempt to get to its individual edit page by manually > constructing the appropriate url retur

Re: Default manager

ngo (eg. admin) will not > work. > What does "will not work" mean, exactly? I recall looking at this in response to a ticket at one point, and the admin behavior I observed was internally consistent and made logical sense to me (if I recall correctly, if something was exc

Re: Default manager

ot; > manager first, otherwise some parts of django (eg. admin) will not > work. > > I find this suboptimal. > > I think that "objects" should always be the default manager, always > present and working. If you want to define a new one, this should not > interfere wi

Default manager

Hi, my understanding about custom managers is that if you want to define a custom manager, you also HAVE to remember to define the "objects" manager first, otherwise some parts of django (eg. admin) will not work. I find this suboptimal. I think that "objects" should a

Re: ModelChoiceField's clean() uses default manager instead of query set

al employee1 item is still displayed & selected) to add some notes ("Remember to buy new furniture") & save. Blam! Can't save because employee is not active, if using the "active=False" manager. (Currently however, admin would be using the default manager so it would allow

Re: ModelChoiceField's clean() uses default manager instead of query set

On Aug 9, 5:49 am, oggie rob <[EMAIL PROTECTED]> wrote: > > That could work. The main point of this thread was to see if there are > > use cases for using the default manager for validation instead of the > > query set because I couldn't really think of any - but I'm s

Re: ModelChoiceField's clean() uses default manager instead of query set

idn't word myself as clearly as I should have :-) Validation is done using a (possibly) different set of data than the choices displayed to the user. > Perhaps it could be changed to only allow choices in the queryset, but > an option is added to ModelChoiceField to use the default manager? That c

Re: ModelChoiceField's clean() uses default manager instead of query set

may guess valid IDs that they should not use (for example if you use user_profile.some_relation as the queryset). Perhaps it could be changed to only allow choices in the queryset, but an option is added to ModelChoiceField to use the default manager? Greetings, Dav

Re: ModelChoiceField's clean() uses default manager instead of query set

e from a list of objects, and > these objects expire over time. I wanted validation to catch the case > of a selected choice expiring and no longer being valid. I have > created a custom ModelChoiceField which works using the query set > instead of the default manager and that suits my pur

Re: ModelChoiceField's clean() uses default manager instead of query set

he reason I came across this in the first place. For some background: The user needs to choose from a list of objects, and these objects expire over time. I wanted validation to catch the case of a selected choice expiring and no longer being valid. I have created a custom ModelChoiceField which works usi

Re: ModelChoiceField's clean() uses default manager instead of query set

le choices.')) > > Is there any reason that shouldn't simply be > self.queryset.get(pk=value) ? > > I came across this in a project when I was trying to work out why it > was allowing choices that I had explicitly filtered out of the > queryset - and of course this explains it. I

ModelChoiceField's clean() uses default manager instead of query set

- and of course this explains it. Is there a reason that the default manager should be used instead of just the original queryset? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" grou