Re: Strange 404 error in admin

[Karen Tracey]

On Mon, Feb 9, 2009 at 11:45 PM, Julien Phalip  wrote:

>
> On Feb 10, 3:19 pm, Karen Tracey  wrote:
> > On Mon, Feb 9, 2009 at 4:17 PM, Julien Phalip  wrote:
> > > Hello again,
> >
> > > I finally fixed it with the following nasty hack:
> >
> > > class Entry(models.Model):
> > >... some fields ...
> >
> > > objects = models.Manager() # Nasty hack
> > >published = PublishedEntryManager()
> >
> > > It seems like the 'change_state' view uses the custom manager instead
> > > of the default one. Explicitly setting 'objects' make it work. If you
> > > can think of a more elegant fix, please let me know ;)
> >
> > ? The first manager declared IS the default manager, so if the first and
> > only manager you had declared was the restrictive one, that was the
> default,
> > so that is what was used.  Declaring an unrestricted manager first, as
> you
> > have done, is the documented way to have an unrestricted default manager
> > plus one or more custom more restrictive managers.
>
> I just checked out the doc again, and I had indeed missed that part on
> the order of managers. Thank you Karen for the pointer.
>
> What I found confusing though, is that the "change list" view
> displayed *all* entries, including the unpublished ones. So that view
> supposedly didn't use the one and only, restrictive, manager that I
> had defined. As opposed to the "change object" view which apparently
> made use of that restrictive manager. In effect, the unpublished
> entries were listed but when you clicked on them you got that 404
> page. Had the unpublished entries not showed up at all (including in
> the change list) I would have thought of an issue with managers
> earlier.
>
> Because it's an old version of Django, and not even a official
> release, that might just be a bug which was then fixed at a later
> stage.
>

I have a vague recollection of trying to recreate a ticket with a
description like that.  It had been written against old admin but I could
not recreate it with newforms-admin.  So yes, I think that was a bug fixed
along the way somewhere to newforms-admin.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 3:19 pm, Karen Tracey  wrote:
> On Mon, Feb 9, 2009 at 4:17 PM, Julien Phalip  wrote:
> > Hello again,
>
> > I finally fixed it with the following nasty hack:
>
> > class Entry(models.Model):
> >        ... some fields ...
>
> >         objects = models.Manager() # Nasty hack
> >        published = PublishedEntryManager()
>
> > It seems like the 'change_state' view uses the custom manager instead
> > of the default one. Explicitly setting 'objects' make it work. If you
> > can think of a more elegant fix, please let me know ;)
>
> ? The first manager declared IS the default manager, so if the first and
> only manager you had declared was the restrictive one, that was the default,
> so that is what was used.  Declaring an unrestricted manager first, as you
> have done, is the documented way to have an unrestricted default manager
> plus one or more custom more restrictive managers.

I just checked out the doc again, and I had indeed missed that part on
the order of managers. Thank you Karen for the pointer.

What I found confusing though, is that the "change list" view
displayed *all* entries, including the unpublished ones. So that view
supposedly didn't use the one and only, restrictive, manager that I
had defined. As opposed to the "change object" view which apparently
made use of that restrictive manager. In effect, the unpublished
entries were listed but when you clicked on them you got that 404
page. Had the unpublished entries not showed up at all (including in
the change list) I would have thought of an issue with managers
earlier.

Because it's an old version of Django, and not even a official
release, that might just be a bug which was then fixed at a later
stage.

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Karen Tracey]

On Mon, Feb 9, 2009 at 4:17 PM, Julien Phalip  wrote:

> Hello again,
>
> I finally fixed it with the following nasty hack:
>
> class Entry(models.Model):
>... some fields ...
>
> objects = models.Manager() # Nasty hack
>published = PublishedEntryManager()
>
> It seems like the 'change_state' view uses the custom manager instead
> of the default one. Explicitly setting 'objects' make it work. If you
> can think of a more elegant fix, please let me know ;)
>

? The first manager declared IS the default manager, so if the first and
only manager you had declared was the restrictive one, that was the default,
so that is what was used.  Declaring an unrestricted manager first, as you
have done, is the documented way to have an unrestricted default manager
plus one or more custom more restrictive managers.

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 7:52 am, Julien Phalip  wrote:
> On Feb 10, 7:41 am, Alex Gaynor  wrote:
>
> > I don't know what manager old forms admin used, but do you have a custom
> > manager that blocks access to some objects.
>
> Thanks Alex for your reply. You've made a really good point which
> helped me track this down. Here are the model and manager:
>
> class PublishedEntryManager(models.Manager):
>         def get_query_set(self):
>                 return super(PublishedEntryManager, 
> self).get_query_set().filter
> (pub_date__lte=datetime.now)
>
> class Entry(models.Model):
>         ... some fields ...
>         pub_date = models.DateTimeField()
>
>         published = PublishedEntryManager()
>
> In fact, if an entry has a pub_date set in the future, then it is not
> accessible in the admin. Somehow the admin seems to be using the
> PublishedEntryManager as default manager. Is there a way to force the
> admin to use the default manager?
>
> Thanks again,
>
> Julien

Hello again,

I finally fixed it with the following nasty hack:

class Entry(models.Model):
... some fields ...

objects = models.Manager() # Nasty hack
published = PublishedEntryManager()

It seems like the 'change_state' view uses the custom manager instead
of the default one. Explicitly setting 'objects' make it work. If you
can think of a more elegant fix, please let me know ;)

Regards,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 10, 7:41 am, Alex Gaynor  wrote:
> I don't know what manager old forms admin used, but do you have a custom
> manager that blocks access to some objects.

Thanks Alex for your reply. You've made a really good point which
helped me track this down. Here are the model and manager:

class PublishedEntryManager(models.Manager):
def get_query_set(self):
return super(PublishedEntryManager, self).get_query_set().filter
(pub_date__lte=datetime.now)

class Entry(models.Model):
... some fields ...
pub_date = models.DateTimeField()

published = PublishedEntryManager()

In fact, if an entry has a pub_date set in the future, then it is not
accessible in the admin. Somehow the admin seems to be using the
PublishedEntryManager as default manager. Is there a way to force the
admin to use the default manager?

Thanks again,

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Alex Gaynor]

On Mon, Feb 9, 2009 at 3:40 PM, Julien Phalip  wrote:

>
> On Feb 9, 7:20 pm, Julien Phalip  wrote:
> > Hi,
> >
> > This is a strange case. I have a simple blog entry model which can be
> > edited in the admin, from the URL that looks like:
> http://www.example.com.au/admin/blog/entry/52/
> >
> > Now, what is strange is that the link above returns a 404. Same with
> > the entry id=51. Yet, entries with id=51,52 do exist.
> >
> > - All other entries (with id < 51) work fine in the admin.
> > - All entries (including id=51,52) work fine on the front end.
> > - Everything works fine when I test it locally on my computer with a
> > replica of the online database.
> >
> > I've never come across something like that, and I'm not sure where to
> > look to debug this. Would you have some hints to suggest?
> >
> > Thanks a lot for your help,
> >
> > Julien
> >
> > PS: It is using a quite old version of Django, a trunk revision
> > between 0.96 and 1.0.
>
> Hi,
>
> I've narrowed down the issue a bit. First, it's using revision 7901,
> that is before newforms-admin.
> The problem is in the 'change_stage' view:
>
> def change_stage(request, app_label, model_name, object_id):
>...
>try:
>manipulator = model.ChangeManipulator(object_id)
>except model.DoesNotExist:
>raise Http404('%s object with primary key %r does not exist' %
> (model_name, escape(object_id)))
>...
>
> When retrieving the manipulator it raises a 'DoesNotExist' exception:
>
> str: Traceback (most recent call last):
>  File "", line 1, in 
>  File "C:\Djangos\catalyst\django\db\models\manipulators.py", line
> 260, in __init__
>self.original_object = self.manager.get(pk=obj_key)
>  File "C:\Djangos\catalyst\django\db\models\manager.py", line 82, in
> get
>return self.get_query_set().get(*args, **kwargs)
>  File "C:\Djangos\catalyst\django\db\models\query.py", line 294, in
> get
>% self.model._meta.object_name)
> DoesNotExist: Entry matching query does not exist.
>
> But I only get that with those two Entry items (id=51,52). Why don't I
> get it for the other items (id < 51)?
>
> I'm really lost here. There must be some kind of corruption in the
> data meaning it cannot find those particular items, but what could it
> be? Again, those 2 blog entries work fine when displayed in the
> frontend.
>
> Do you think it could be a bug in that particular revision of Django
> I'm using?
>
> Any help would be appreciated.
>
> Julien
> >
>
I don't know what manager old forms admin used, but do you have a custom
manager that blocks access to some objects.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." --Voltaire
"The people's good is the highest law."--Cicero

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Strange 404 error in admin

[Julien Phalip]

On Feb 9, 7:20 pm, Julien Phalip  wrote:
> Hi,
>
> This is a strange case. I have a simple blog entry model which can be
> edited in the admin, from the URL that looks 
> like:http://www.example.com.au/admin/blog/entry/52/
>
> Now, what is strange is that the link above returns a 404. Same with
> the entry id=51. Yet, entries with id=51,52 do exist.
>
> - All other entries (with id < 51) work fine in the admin.
> - All entries (including id=51,52) work fine on the front end.
> - Everything works fine when I test it locally on my computer with a
> replica of the online database.
>
> I've never come across something like that, and I'm not sure where to
> look to debug this. Would you have some hints to suggest?
>
> Thanks a lot for your help,
>
> Julien
>
> PS: It is using a quite old version of Django, a trunk revision
> between 0.96 and 1.0.

Hi,

I've narrowed down the issue a bit. First, it's using revision 7901,
that is before newforms-admin.
The problem is in the 'change_stage' view:

def change_stage(request, app_label, model_name, object_id):
...
try:
manipulator = model.ChangeManipulator(object_id)
except model.DoesNotExist:
raise Http404('%s object with primary key %r does not exist' %
(model_name, escape(object_id)))
...

When retrieving the manipulator it raises a 'DoesNotExist' exception:

str: Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Djangos\catalyst\django\db\models\manipulators.py", line
260, in __init__
self.original_object = self.manager.get(pk=obj_key)
  File "C:\Djangos\catalyst\django\db\models\manager.py", line 82, in
get
return self.get_query_set().get(*args, **kwargs)
  File "C:\Djangos\catalyst\django\db\models\query.py", line 294, in
get
% self.model._meta.object_name)
DoesNotExist: Entry matching query does not exist.

But I only get that with those two Entry items (id=51,52). Why don't I
get it for the other items (id < 51)?

I'm really lost here. There must be some kind of corruption in the
data meaning it cannot find those particular items, but what could it
be? Again, those 2 blog entries work fine when displayed in the
frontend.

Do you think it could be a bug in that particular revision of Django
I'm using?

Any help would be appreciated.

Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Strange 404 error in admin

[Julien Phalip]

Hi,

This is a strange case. I have a simple blog entry model which can be
edited in the admin, from the URL that looks like:
http://www.example.com.au/admin/blog/entry/52/

Now, what is strange is that the link above returns a 404. Same with
the entry id=51. Yet, entries with id=51,52 do exist.

- All other entries (with id < 51) work fine in the admin.
- All entries (including id=51,52) work fine on the front end.
- Everything works fine when I test it locally on my computer with a
replica of the online database.

I've never come across something like that, and I'm not sure where to
look to debug this. Would you have some hints to suggest?

Thanks a lot for your help,

Julien

PS: It is using a quite old version of Django, a trunk revision
between 0.96 and 1.0.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---