strange behaviour of custom view based on date_based.object_detail - random 404
I've got some strange problems in my hosting enviroment using mod_wsgi
like that:
WSGIDaemonProcess mygroup user=myuser group=users processes=3
threads=10 display-name=mygroup
Enviroment:
python-2.6.1
python-apache-2.2.11
psycopg2-2.0.11
apache-mod_wsgi-2.5
glibc-2.10.1
The problem is that random requests (originating from the same client
which is ab -n 1000 -c 3 http://...) generates 404, because these
requests generates different sql:
Query which is OK as I think:
SELECT "pressroom_article"."id", "pressroom_article"."pub_date",
"pressroom_article"."headline", "pressroom_article"."slug",
"pressroom_article"."summary", "pressroom_article"."body",
"pressroom_article"."author_id", "pressroom_article"."publish",
"pressroom_article"."enable_comments" FROM "pressroom_article"
WHERE ("pressroom_article"."pub_date" <= E'2009-09-29 13:54:00.806995'
AND "pressroom_article"."publish" = true AND
"pressroom_article"."pub_date" BETWEEN E'2009-09-29 00:00:00' and
E'2009-09-29 23:59:59.99' AND "pressroom_article"."slug" =
E'spotting-na-jfk' AND "pressroom_article"."pub_date" <= E'2009-09-29
13:54:00.808648' ) ORDER BY "pressroom_article"."pub_date" DESC
^^^
And the one which renders 404 is
WHERE ("pressroom_article"."pub_date" <= E'2009-09-29 06:55:06.859015'
AND "pressroom_article"."publish" = true AND
The question is - what's wrong? it happens in different projects.
My setting:
TIME_ZONE = 'Europe/Warsaw'
My Model is (it's modified part of
http://code.google.com/p/django-pressroom/):
class ArticleManager(models.Manager):
def get_published(self):
return self.filter(publish=True, pub_date__lte=datetime.now)
def get_drafts(self):
return self.filter(publish=False)
class Article(models.Model):
pub_date = models.DateTimeField("Publish date", default=datetime.now)
headline = models.CharField(max_length=200)
slug = models.SlugField(help_text='A "Slug" is a unique URL-friendly
title for an object.')
summary = models.TextField(help_text="A single paragraph summary or
preview of the article.")
body = models.TextField("Body text")
#author = models.CharField(max_length=100)
author = models.ForeignKey(User, verbose_name="Author" )
publish = models.BooleanField("Publish on site", default=True,
help_text='Articles will not appear on
the site until their "publish date".')
sections = models.ManyToManyField('Section', related_name='articles')
photos = models.ManyToManyField(Photo, related_name='articles',
null=True, blank=True)
documents = models.ManyToManyField('Document',
related_name='articles', null=True, blank=True)
enable_comments = models.BooleanField(default=True)
# Custom article manager
objects = ArticleManager()
[...]
And my view is:
def article_detail(request, *args, **kwargs):
kwargs['queryset'] = Article.objects.get_published()
return date_based.object_detail(request, *args, **kwargs)
Another view in another project which act the same is:
def my_akt_detail(request, *args, **kwargs):
kwargs['queryset'] =
Akt.objects.select_related('zrodla').filter(visible_since__lte=datetime.now())
return date_based.object_detail(request, *args, **kwargs)
In above views I use intentionally my own views to get rid of cache-like
queryset behaviour like
http://pascut.com/2008/08/16/django-generic-views-cache-behavior/
It does not matter, if in my view i return
Article.objects.get_published() or Article.objects.all() - It's probably
because default value of allow_future=False in date_based.object_detail
Strange thing is that 404 NOT FOUND appears random, sometimes it's 25%,
30, or even about 70% times.
For now i'm not sure, if original date_based.object_detail is buggy in
my enviroment.
Any ideas?
--
B.
--~--~-~--~~~---~--~~
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: Django and Ajax (mootools/clientcide) Fupdate encoding problems
Karen Tracey pisze: > > Sharing with the list what, exactly, the 'results far from expected' > look like would be a start. I assume from the subject that you are > getting some sort of encoding exception, but without the traceback it is > a bit difficult to say where exactly the problem is. Indeed, i'd have been more precise... "far from expected" means, that characters "śś" are saved as "ść ść" There's no encoding exception, so i think that the reason is bad encodnig by Fupdate, or just Django can't handle proper encoding of correct data supplied by Fupdate. I've found out that clientcide Fupdate makes some "magic" with form data, so I've changed a little code of clientcide Fupdate (http://groups.google.com/group/clientside/browse_frm/thread/e72931ed9260369d), and it works well now, I don't know if this problem is more server or client side specyfic... -- Bartek --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django and Ajax (mootools/clientcide) Fupdate encoding problems
Hi Im using clientcide fupdate which generates ajax request: http://dpaste.com/38671/ My post data includes some national (polish) characters, when i try to save them i get results far from expected. My view is at http://dpaste.com/38672/ What would be the best idea to handle this problem? Where does it originate? Any idea where to start investigation? -- Bartek --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
date_list in date_based.archive_index and date_based.archive_year but why not in archive_list and archve_month?
Hi Why there are not extra_centext date_list in date_based views except archive_index and archive_year? I've found this: http://code.djangoproject.com/ticket/3274 but this patch isn't applied in Django-1.0.2-final.tar.gz? What is the best way to have date_list in archive_list and archive_month except modifying Django generic views code? Is the the custom template tag with passed queryset as variable the only way? -- Bartek --~--~-~--~~~---~--~~ 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: pagination
Konstantin S pisze:
> Hello!
> second one I found at code.google.com. (Url is
> http://code.google.com/p/django-pagination/). Which one would you
> recommend ?
This one works well for me (it uses the built-one), but remember not to
use {% if object_list %} before pagination tags in your template - the
"if" tag evaluates the queryset, that was cause of big overhead in one
of my apps..
Discussion few months ago:
http://www.tinyurl.pl?Q4IaEv3v
--
jid: b.rad...@chrome.pl
--~--~-~--~~~---~--~~
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: django 1.0.2, django_pagination-1.0.5, postgresql, LIMIT & OFFSET question
Karen Tracey pisze:
> On Wed, Feb 4, 2009 at 3:01 AM, Bartek SQ9MEV <mailto:bar...@sq9mev.info>> wrote:
[...]
> So, any idea where's the clue?
> Is it possible to use django-pagination with generic views without so
> senseless overhead?
>
The cause was the {% if posts_list %} tag, which evaluates the queryset
before the limit was applied. Now it's obvious for me ;).
Django-pagination works well.
--
Bartek
--~--~-~--~~~---~--~~
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: django 1.0.2, django_pagination-1.0.5, postgresql, LIMIT & OFFSET question
Bartek pisze: > so... looks like everytime I need 20 Post items my database is hit by > query returning all records... I find it a big overhead, and my app > suffers from that... Today I'm still investigating this issue, and I've just tried to use Paginator object as described at http://docs.djangoproject.com/en/dev/topics/pagination/#topics-pagination with my Post model described ina my previous post. Funny thing is that it's OK - sql for any page is: SELECT "galgather_post"."id", "galgather_post"."group_id", "galgather_post"."messageid", "galgather_post"."subject", "galgather_post"."author_id", "galgather_post"."posting_date", "galgather_post"."date_added" FROM "galgather_post" ORDER BY "galgather_post"."posting_date" DESC LIMIT 10 OFFSET 10 triggered by: posts=Post.objects.all() p=Paginator(posts,10) page2=p.page(2) page2.object_list So, any idea where's the clue? Is it possible to use django-pagination with generic views without so senseless overhead? -- Bartek --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to delete template fragment cache?
Hi all, I'm quite newbie in Django.
I use template fragment caching ({% cache ...%}...{% endcache %}. This
fragment changes rather seldom, changes originate only from admin site,
są for me its obvious to delete cache at adding objects from admin, and
use quite large tiemeout for my caches.
How can I delete cache for particular fragments at saving objects?
I know I should use cache.delete('a'), but how can I get key for
particular fragment?
What is better idea? Use signals (I do not know too mouch about them
yet)or just overwrite model_save method?
I use memcached backend.
--
Pozdrawiam
Bartek
jid: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
