Re: Django 1.2.1, Postgres 8.3 - Cast (text to int) Issue
Hi,
Fixed it.
I took the following (from http://bit.ly/bO8m9A):
Comment.objects.filter(content_type=ContentType.objects.get_for_model(Entry ),
object_pk__in=Entry.objects.filter(category="some category")).
and used it as follows:
Comment.objects.filter(content_type=ContentType.objects.get_for_model(Entry),
object_pk__in=Entry.objects.filter(title=self.title))
With Django 1.2, Postgres 8.3, and 'postgresql_psycopg2', this no
longer works. Reason is that "object_pk" in the Comment model is a
"text" type in Postgres, whereas Entry.id is an "integer" - and there
is no longer an automatic conversion between the two.
So, my fix was to break things down as follows:
comment_list=Comment.objects.filter(content_type=ContentType.objects.get_for_model(Entry))
e=Entry.objects.filter(title=self.title)
entry_object_ids_string = str([ei.id for ei in e])
comment_tuple=comment_list.filter(object_pk__in=entry_object_ids_string).values_list('comment',
flat=True)
This seems to work fine.
This post is really a follow-on from "Filtering contrib.comments on
related object property?": http://bit.ly/bO8m9A
FYI - I wanted to use this to enable my Djapian-based on-site search
to be able to search comments that people had left. Again, seems to
work.
Thanks,
R
On Jul 14, 8:45 pm, rd-london <roland.d...@gmail.com> wrote:
> Hi,
> Wonder if someone can help.
> I have a piece of code (filtched from elsewhere) that retrieves the
> comments for a particular Entry (blog post):
>
> Comment.objects.filter(content_type=ContentType.objects.get_for_model(Entry ),
> object_pk__in=Entry.objects.filter(title=self.title))
>
> Problem is, that with Postgres 8.3 (and seemingly Django 1.2.1), this
> command fails:
>
> "
> django.db.utils.DatabaseError: operator does not exist: text = integer
> HINT: No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
> "
>
> Having searched around in various forms this appears to be a sort of
> known problem (seehttp://code.djangoproject.com/ticket/10015).
>
> The issue is that object_py in Comments is a "text" field, whereas the
> id field in Entry is an int - hence a cast is required. I can make the
> actual SQL work in Postgres 8.3 by altering the start of the WHERE to
> be:
>
> "WHERE (cast(django_comments.object_pk as int) IN (SELECT" i.e.
> adding the 'cast'.
>
> So, my question is: what's the best way to go about this in Django
> 1.2.1 with Postgres 8.3? (8.3.8 to be exact). Any thoughts/
> recommendations most welcome.
>
> FYI - this is for use with Djapian.
>
> Thanks,
> R
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
Django 1.2.1, Postgres 8.3 - Cast (text to int) Issue
Hi, Wonder if someone can help. I have a piece of code (filtched from elsewhere) that retrieves the comments for a particular Entry (blog post): Comment.objects.filter(content_type=ContentType.objects.get_for_model(Entry), object_pk__in=Entry.objects.filter(title=self.title)) Problem is, that with Postgres 8.3 (and seemingly Django 1.2.1), this command fails: " django.db.utils.DatabaseError: operator does not exist: text = integer HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. " Having searched around in various forms this appears to be a sort of known problem (see http://code.djangoproject.com/ticket/10015). The issue is that object_py in Comments is a "text" field, whereas the id field in Entry is an int - hence a cast is required. I can make the actual SQL work in Postgres 8.3 by altering the start of the WHERE to be: "WHERE (cast(django_comments.object_pk as int) IN (SELECT" i.e. adding the 'cast'. So, my question is: what's the best way to go about this in Django 1.2.1 with Postgres 8.3? (8.3.8 to be exact). Any thoughts/ recommendations most welcome. FYI - this is for use with Djapian. Thanks, R -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: has_delete_permission not called in an admin template?
OK, so my conclusion having examined the code listed at http://bit.ly/7ZrKHl
is that my solution is thread-safe. There's no if...else... type logic
happening in my solution so should be fine.
R
On Nov 20, 5:22 pm, rd-london <roland.d...@gmail.com> wrote:
> And ... yes there does seem to be a better way.
>
> Define own version of "changelist_view" e.g.:
>
> def changelist_view(self, request, extra_context=None):
> extra_context={ 'has_delete_permission': self.has_delete_permission
> (request) }
> return super(MyCommentsAdmin, self).changelist_view(request,
> extra_context)
>
> However - as this post suggests -http://bit.ly/7ZrKHl- is this
> thread safe?
> Thanks for any thoughts anyone.
>
> R
>
> On Nov 20, 5:02 pm, rd-london <roland.d...@gmail.com> wrote:
>
>
>
> > Right, I've worked out why this is:
>
> > django/contrib/admin/options.py - def changelist_view(self, request,
> > extra_context=None): contains the line:
>
> > context = {
> > 'title': cl.title,
> > 'is_popup': cl.is_popup,
> > 'cl': cl,
> > 'media': media,
> > 'has_add_permission': self.has_add_permission(request),
> > 'root_path': self.admin_site.root_path,
> > 'app_label': app_label,
> > 'action_form': action_form,
> > 'actions_on_top': self.actions_on_top,
> > 'actions_on_bottom': self.actions_on_bottom,
> > }
>
> > So, it doesn't add "has_delete_permission" to the context (nor
> > "has_change_permission") for that matter. Simple fix:
>
> > context = {
> > 'title': cl.title,
> > 'is_popup': cl.is_popup,
> > 'cl': cl,
> > 'media': media,
> > 'has_add_permission': self.has_add_permission(request),
> > addedhere ---> 'has_delete_permission':
> > self.has_delete_permission(request), <- added here
> > 'root_path': self.admin_site.root_path,
> > 'app_label': app_label,
> > 'action_form': action_form,
> > 'actions_on_top': self.actions_on_top,
> > 'actions_on_bottom': self.actions_on_bottom,
> > }
>
> > ... but ... but ... surely that comes from the land of Harry the
> > Hacker?
> > Isn't there a better way to do this, or is this a genuine bug?
>
> > Any help or thoughts very welcome,
>
> > Cheers
> > R
>
> > On Nov 20, 3:18 pm, rd-london <roland.d...@gmail.com> wrote:
>
> > > Hi,
> > > Wonder if anyone can help.
>
> > > Have following chunk in my own change_list.html template:
>
> > > {% block object-tools %}
> > >
> > > {% if has_add_permission %}
> > >
> > > > > title="Add Comment" class="addlink">
> > > {% blocktrans with cl.opts.verbose_name as name %}Add
> > > {{ name }}{% endblocktrans %}
> > >
> > >
> > > {% endif %}
> > > {% if has_delete_permission %}
> > >
> > > My thing goes here
> > >
> > > {% endif %}
> > >
>
> > > {% endblock %}
>
> > > Created a user that has delete permissions. Got my own ModelAdmin and
> > > have checked using the debugger that the user does indeed have delete
> > > permissions.
>
> > > The "def has_add_permission" fn in contrib/admin/options.py *is* being
> > > called (I've put "import pdb;pdb.set_trace()" there to check), whereas
> > > def has_delete_permission is not - and I can't work out for the life
> > > of me why not.
>
> > > Anyone help at all?
>
> > > Thanks,
> > > R
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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=.
Re: has_delete_permission not called in an admin template?
And ... yes there does seem to be a better way.
Define own version of "changelist_view" e.g.:
def changelist_view(self, request, extra_context=None):
extra_context={ 'has_delete_permission': self.has_delete_permission
(request) }
return super(MyCommentsAdmin, self).changelist_view(request,
extra_context)
However - as this post suggests - http://bit.ly/7ZrKHl - is this
thread safe?
Thanks for any thoughts anyone.
R
On Nov 20, 5:02 pm, rd-london <roland.d...@gmail.com> wrote:
> Right, I've worked out why this is:
>
> django/contrib/admin/options.py - def changelist_view(self, request,
> extra_context=None): contains the line:
>
> context = {
> 'title': cl.title,
> 'is_popup': cl.is_popup,
> 'cl': cl,
> 'media': media,
> 'has_add_permission': self.has_add_permission(request),
> 'root_path': self.admin_site.root_path,
> 'app_label': app_label,
> 'action_form': action_form,
> 'actions_on_top': self.actions_on_top,
> 'actions_on_bottom': self.actions_on_bottom,
> }
>
> So, it doesn't add "has_delete_permission" to the context (nor
> "has_change_permission") for that matter. Simple fix:
>
> context = {
> 'title': cl.title,
> 'is_popup': cl.is_popup,
> 'cl': cl,
> 'media': media,
> 'has_add_permission': self.has_add_permission(request),
> addedhere ---> 'has_delete_permission':
> self.has_delete_permission(request), <- added here
> 'root_path': self.admin_site.root_path,
> 'app_label': app_label,
> 'action_form': action_form,
> 'actions_on_top': self.actions_on_top,
> 'actions_on_bottom': self.actions_on_bottom,
> }
>
> ... but ... but ... surely that comes from the land of Harry the
> Hacker?
> Isn't there a better way to do this, or is this a genuine bug?
>
> Any help or thoughts very welcome,
>
> Cheers
> R
>
> On Nov 20, 3:18 pm, rd-london <roland.d...@gmail.com> wrote:
>
> > Hi,
> > Wonder if anyone can help.
>
> > Have following chunk in my own change_list.html template:
>
> > {% block object-tools %}
> >
> > {% if has_add_permission %}
> >
> > > title="Add Comment" class="addlink">
> > {% blocktrans with cl.opts.verbose_name as name %}Add
> > {{ name }}{% endblocktrans %}
> >
> >
> > {% endif %}
> > {% if has_delete_permission %}
> >
> > My thing goes here
> >
> > {% endif %}
> >
>
> > {% endblock %}
>
> > Created a user that has delete permissions. Got my own ModelAdmin and
> > have checked using the debugger that the user does indeed have delete
> > permissions.
>
> > The "def has_add_permission" fn in contrib/admin/options.py *is* being
> > called (I've put "import pdb;pdb.set_trace()" there to check), whereas
> > def has_delete_permission is not - and I can't work out for the life
> > of me why not.
>
> > Anyone help at all?
>
> > Thanks,
> > R
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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=.
Re: has_delete_permission not called in an admin template?
Right, I've worked out why this is:
django/contrib/admin/options.py - def changelist_view(self, request,
extra_context=None): contains the line:
context = {
'title': cl.title,
'is_popup': cl.is_popup,
'cl': cl,
'media': media,
'has_add_permission': self.has_add_permission(request),
'root_path': self.admin_site.root_path,
'app_label': app_label,
'action_form': action_form,
'actions_on_top': self.actions_on_top,
'actions_on_bottom': self.actions_on_bottom,
}
So, it doesn't add "has_delete_permission" to the context (nor
"has_change_permission") for that matter. Simple fix:
context = {
'title': cl.title,
'is_popup': cl.is_popup,
'cl': cl,
'media': media,
'has_add_permission': self.has_add_permission(request),
addedhere ---> 'has_delete_permission':
self.has_delete_permission(request), <- added here
'root_path': self.admin_site.root_path,
'app_label': app_label,
'action_form': action_form,
'actions_on_top': self.actions_on_top,
'actions_on_bottom': self.actions_on_bottom,
}
... but ... but ... surely that comes from the land of Harry the
Hacker?
Isn't there a better way to do this, or is this a genuine bug?
Any help or thoughts very welcome,
Cheers
R
On Nov 20, 3:18 pm, rd-london <roland.d...@gmail.com> wrote:
> Hi,
> Wonder if anyone can help.
>
> Have following chunk in my own change_list.html template:
>
> {% block object-tools %}
>
> {% if has_add_permission %}
>
> title="Add Comment" class="addlink">
> {% blocktrans with cl.opts.verbose_name as name %}Add
> {{ name }}{% endblocktrans %}
>
>
> {% endif %}
> {% if has_delete_permission %}
>
> My thing goes here
>
> {% endif %}
>
>
> {% endblock %}
>
> Created a user that has delete permissions. Got my own ModelAdmin and
> have checked using the debugger that the user does indeed have delete
> permissions.
>
> The "def has_add_permission" fn in contrib/admin/options.py *is* being
> called (I've put "import pdb;pdb.set_trace()" there to check), whereas
> def has_delete_permission is not - and I can't work out for the life
> of me why not.
>
> Anyone help at all?
>
> Thanks,
> R
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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=.
has_delete_permission not called in an admin template?
Hi,
Wonder if anyone can help.
Have following chunk in my own change_list.html template:
{% block object-tools %}
{% if has_add_permission %}
{% blocktrans with cl.opts.verbose_name as name %}Add
{{ name }}{% endblocktrans %}
{% endif %}
{% if has_delete_permission %}
My thing goes here
{% endif %}
{% endblock %}
Created a user that has delete permissions. Got my own ModelAdmin and
have checked using the debugger that the user does indeed have delete
permissions.
The "def has_add_permission" fn in contrib/admin/options.py *is* being
called (I've put "import pdb;pdb.set_trace()" there to check), whereas
def has_delete_permission is not - and I can't work out for the life
of me why not.
Anyone help at all?
Thanks,
R
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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=.
Re: Template processing/pre-processing
Not worry, found work-a-round using MEDIA_URL. On Oct 30, 4:39 pm, rd-london <roland.d...@gmail.com> wrote: > Hi, > > I'd like to write some code, probably middleware, that look at various > types of HTML in templates and prepends a setting from settings.py. > > For example, I'd like to pickup all .js, .css, .jpg, .png, .gif - and > stick a custom setting from settings.py on the front - effectively a > path. > > Ideally, I'd like to do this by-project, so one project will have one > such setting in a settings.py, another project will have nother. > > I'm not looking for a solution (although one would certainly be > welcome), but where to start looking would be handy. Feels like its > some kind of template pre-processing middleware - but anyone any > pointers/tips? > > Many thanks for any help, > R --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Template processing/pre-processing
Hi, I'd like to write some code, probably middleware, that look at various types of HTML in templates and prepends a setting from settings.py. For example, I'd like to pickup all .js, .css, .jpg, .png, .gif - and stick a custom setting from settings.py on the front - effectively a path. Ideally, I'd like to do this by-project, so one project will have one such setting in a settings.py, another project will have nother. I'm not looking for a solution (although one would certainly be welcome), but where to start looking would be handy. Feels like its some kind of template pre-processing middleware - but anyone any pointers/tips? Many thanks for any help, R --~--~-~--~~~---~--~~ 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: nginx, apache, and odd admin error
Sorry meant to add. Key sources of information: - http://wiki.nginx.org/NginxHttpProxyModule#proxy_redirect - http://forum.slicehost.com/comments.php?DiscussionID=3065 R On Oct 24, 8:58 pm, rd-london <roland.d...@gmail.com> wrote: > Looks like I nailed the reverse proxy arrangement, apologies to all on > this mailing list, this particular issue isn't something specific to > Django: > > - Definitely do not need to configure SetRemoteAddrFromForwardedFor > middleware > (http://code.djangoproject.com/browser/django/trunk/django/middleware/...) > in Django (not with nginx at least). > > - In nginx, the key bits in the config files are: > > # So this deals with host IP *and* port > proxy_set_header Host $host:$server_port; > proxy_redirect default; > > - What's neat is that you can use nginx and the default Django > webserver for debugging, then switch a config setting in nginx, > restart nginx and be using Apache. > > Tom - re: the admin on a separate port - thanks - sounds good. > R > > On Oct 24, 12:46 pm, Tom Evans <tevans...@googlemail.com> wrote: > > > On Fri, 2009-10-23 at 10:05 -0700, rd-london wrote: > > > > On a slightly separate note - forgetting the reverse proxy arrangment > > > for a moment, how would one serve admin on a separate port? > > > > Thanks for any help, > > > R > > > Can't help with the other bit, but - in apache or nginx? > > > In apache you'd simply define a second vhost on a different port. In the > > main vhost you would deny requests to /admin, and in the second vhost > > deny requests not to /admin. > > > Cheers > > > Tom --~--~-~--~~~---~--~~ 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: nginx, apache, and odd admin error
Looks like I nailed the reverse proxy arrangement, apologies to all on this mailing list, this particular issue isn't something specific to Django: - Definitely do not need to configure SetRemoteAddrFromForwardedFor middleware ( http://code.djangoproject.com/browser/django/trunk/django/middleware/http.py?rev=11000#L33) in Django (not with nginx at least). - In nginx, the key bits in the config files are: # So this deals with host IP *and* port proxy_set_headerHost $host:$server_port; proxy_redirect default; - What's neat is that you can use nginx and the default Django webserver for debugging, then switch a config setting in nginx, restart nginx and be using Apache. Tom - re: the admin on a separate port - thanks - sounds good. R On Oct 24, 12:46 pm, Tom Evans <tevans...@googlemail.com> wrote: > On Fri, 2009-10-23 at 10:05 -0700, rd-london wrote: > > > On a slightly separate note - forgetting the reverse proxy arrangment > > for a moment, how would one serve admin on a separate port? > > > Thanks for any help, > > R > > Can't help with the other bit, but - in apache or nginx? > > In apache you'd simply define a second vhost on a different port. In the > main vhost you would deny requests to /admin, and in the second vhost > deny requests not to /admin. > > Cheers > > Tom --~--~-~--~~~---~--~~ 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: nginx, apache, and odd admin error
Right, well, replying to myself ... and hoping someone else will jump in, here's where I'm upto ... Having read around a bit, I figured that the reverse proxy my well be losing the original IP address, so I looked into configuring "SetRemoteAddrFromForwardedFor" (http://code.djangoproject.com/browser/ django/trunk/django/middleware/http.py?rev=11000#L33). Whilst this certainly helped retain the original IP address (I setup reporting to apache_error.log via my .wsgi file), what became clear is that it's not the IP address that's the problem, it's the *port*. So, I try logging in via http://127.0.0.1:81/admin/ and end up being redirected to http://127.0.0.1/admin/ (port 81 is managed and served via nginx). However, if I login to admin via my apache port, 127.0.0.1:96 I don't suffer in this way So, any thoughts anyone? On a slightly separate note - forgetting the reverse proxy arrangment for a moment, how would one serve admin on a separate port? Thanks for any help, R On Oct 21, 10:25 pm, rd-london <roland.d...@gmail.com> wrote: > Hi, > Wonder if someone can help.This issue is all with a local dev > situation, so this isn't live. > > I have nginx running on port 81 e.g.http://127.0.0.1:81/and serving > static media - which in turn proxies through to Apache running on port > 96. All works fine (apart from the issue I outline below) - so I can > browse my content no problem. > > The issues relate to the admin interface. > > If I request the admin interface athttp://127.0.0.1:81/admin/, the > admin login window appears but on "log in", I am taken to > http://127.0.0.1/admin/ > - which of course 404's i.e. doesn't work (there appears to be some > kind of redirect going on). > > Once I've got this 404, if I then requesthttp://127.0.0.1:81/admin/ > again, the full "logged in" interface now comes up - i.e. I am now > *not* redirected and am now logged in. > > Carrying on ... if I try to edit some content, all works fine until I > try to Save or Save and Continue ... at which point again I am > redirected to admin URL minus the port (incidentally the item is then > saved). > > If I work directly on the Apache interface athttp://127.0.0.1:96/I > don't have this problem. > > Anyone any suggestions as to what's going on and how to fix it? > > Many thanks, > R --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
nginx, apache, and odd admin error
Hi, Wonder if someone can help.This issue is all with a local dev situation, so this isn't live. I have nginx running on port 81 e.g. http://127.0.0.1:81/ and serving static media - which in turn proxies through to Apache running on port 96. All works fine (apart from the issue I outline below) - so I can browse my content no problem. The issues relate to the admin interface. If I request the admin interface at http://127.0.0.1:81/admin/, the admin login window appears but on "log in", I am taken to http://127.0.0.1/admin/ - which of course 404's i.e. doesn't work (there appears to be some kind of redirect going on). Once I've got this 404, if I then request http://127.0.0.1:81/admin/ again, the full "logged in" interface now comes up - i.e. I am now *not* redirected and am now logged in. Carrying on ... if I try to edit some content, all works fine until I try to Save or Save and Continue ... at which point again I am redirected to admin URL minus the port (incidentally the item is then saved). If I work directly on the Apache interface at http://127.0.0.1:96/ I don't have this problem. Anyone any suggestions as to what's going on and how to fix it? Many thanks, R --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
