It is indeed a bug.
On Fri, Oct 7, 2011 at 10:19 AM, Guilherme Salgado
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 of the default manager (a
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
befor
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.
>>
>> His proposal seems to center around forcibly making "objects" *always
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 manager returning an unfiltered QuerySet, so I'm not
+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
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 that's a downside (not to ment
ger 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, or you have to do some overriding in the ModelAdmin
>
o, 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 this suboptimal.
I find it
> 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
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
a
> backwards-incompatible change.
Agreed 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 di
ical 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 returned a 404). I can't tell from what
> you&
gt; 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 excluded in the default manager, it
herwise 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 with "objects" being
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
ctivity1 (the original 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
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&#
> 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 sure there
> could well be some.
Like the one I explained? :)
bly didn'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?
ople 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
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 using the query set
> instead
least that's the 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 ModelCh
he available 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 thi
of the
queryset - 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&quo
24 matches
Mail list logo
