ModelBackend should have a get_anonymous_user method
ModelBackend should provide a method to get a fresh instance of AnonymousUser, and use this method to set a new instance of AnonymousUser in django.contrib.auth.get_user and django.contrib.auth.logout i've created a ticket https://code.djangoproject.com/ticket/17254 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelBackend should have a get_anonymous_user method
Hi Ric, On 18 November 2011 19:53, Ric wrote: > ... > i've created a ticket > https://code.djangoproject.com/ticket/17254 Thank you for your contributions of late. Please note that you don't need to email django-developers when you create a new ticket; we receive notifications through django-updates and monitor Trac. Simon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for review / Multiple time zone support for datetime representation
On Nov 1, 4:58 pm, Aymeric Augustin
wrote:
> I'm glad to announce that the time zone support branch is ready for review.
I did a simple performance test on PostgreSQL (fetch 1000 objs with
datetime field) and could not see any real performance regressions. I
did the same for template rendering, and according to my tests,
setting USE_TZ=True leads to around 10% slower template rendering (in
a template doing nothing else than rendering 1000 datetime fields). I
could not see any regressions when USE_TZ was False compared to Django
trunk. So, at least according to this simple test there is nothing to
worry about performance-wise. The end of the post includes the test
code for reference.
> The docs are supposed to explain everything you need, and I described many
> design decisions in my weekly check-ins, so I'm purposefully keeping this
> email short on details :)
This part of the documentation raises one question:
"""
Unfortunately, during DST transitions, some datetimes don't exist or
are
ambiguous. In such situations, pytz_ raises an exception. Other
:class:`~datetime.tzinfo` implementations, such as the local time zone
used as
a fallback when pytz_ isn't installed, may raise an exception or
return
inaccurate results. That's why you should always create aware datetime
objects
when time zone support is enabled.
"""
Won't this lead to web applications where errors suddenly start
popping up all over the place, but only twice (or once?) a year?
A setting "ON_NAIVE_DATETIMES=[do_nothing|log|error]" could be nice,
at least for testing. This way you could spot the errors early on. I
don't know if that would be too expensive performance wise, though.
> There is only one outstanding issue that I know of. `QuerySet.dates()`
> operates in the database timezone, ie. UTC, while an end user would expect it
> to take into account its current time zone. This affects `date_hierarchy` in
> the admin and the date based generic views. The same problem also exists for
> the `year`, `month`, `day`, and `week_day` lookups.
>
> Under PostgreSQL, provided the current time zone has a valid name (e.g. it's
> provided by pytz), we could temporarily set the connection's timezone to this
> time zone and restore it to UTC afterwards. With other backends, I can't
> think of a simpler solution than fetching all values and doing the
> aggregation in Python. Neither of these thrills me, so for the time being,
> I've documented this as a known limitation.
I don't see this as a major issue, except if Django needs to support
this behaviour for backwards compatibility reasons. But as this is
documented as a limitation, not as a "feature", this is fine as is.
It would be nice to fix this in the future.
For PostgreSQL, tracking the current time zone for the connection
seems a bit hard - we can't rely a SET TIME ZONE is really going to be
in effect, unless we also track rollbacks/commits (see #17062). And
changing it for every DB query seems bad, too.
One idea is to use "SELECT col AT TIME ZONE 'GMT+2' as col". This way
the session time zone doesn't need to be changed. For example:
> SET TIME ZONE 'UTC';
> create table testt(dt timestamptz);
> insert into testt values(now());
> select dt at time zone 'GMT+2' as dt from testt;
2011-11-18 07:06:47.834771
> select dt at time zone 'Europe/Helsinki' as dt from testt;
2011-11-18 11:06:47.834771
Oracle seems to have a similar feature [1]. I don't know if other
databases offer similar functionality. MySQL has probably support for
something similar when using TIMESTAMP columns.
But as said, I don't see this as a major issue. It would be nice to
support this some day.
I haven't read the code in detail, but what I have seen seems to be
very good quality code. I hope to see this in trunk soon.
- Anssi
[1]: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm
Search for AT TIME ZONE.
The test code
from django.core.management import setup_environ
import settings
setup_environ(settings)
# M is a model with one text field and one datetime field.
from tester.models import M
from datetime import datetime
from django.db import connection
from django.template import Template
from django.template import Context
import pytz
def load_data():
bulk = []
for i in range(0, 1000):
bulk.append(M(f1='foob', dt=datetime.now()))
M.objects.bulk_create(bulk)
load_data()
start = datetime.now()
for i in range(0, 10):
for obj in M.objects.all():
pass
print datetime.now() - start
print obj.dt
templ = """
{% for obj in objects %}
{{ obj.dt }}
{% endfor %}
"""
t = Template(templ)
c = Context({'objects': list(M.objects.all())})
start = datetime.now()
for i in range(0, 10):
output = t.render(c)
print datetime.now() - start
print 'The template generated... %s' % output[0:100]
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@goog
Re: Request for review / Multiple time zone support for datetime representation
Hi Anssi, 2011/11/18 Anssi Kääriäinen > So, at least according to this simple test there is nothing to > worry about performance-wise. > Thanks for the performance tests! They were still on my TODO list. > This part of the documentation raises one question: > """ > Unfortunately, during DST transitions, some datetimes don't exist or > are > ambiguous. In such situations, pytz_ raises an exception. Other > :class:`~datetime.tzinfo` implementations, such as the local time zone > used as > a fallback when pytz_ isn't installed, may raise an exception or > return > inaccurate results. That's why you should always create aware datetime > objects > when time zone support is enabled. > """ > > Won't this lead to web applications where errors suddenly start > popping up all over the place, but only twice (or once?) a year? > If you're using aware datetimes internally, user input is the only source of naive datetimes in local time. Ambiguous values are handled properly by a validation error: http://myks.org/stuff/django-tz-demo-2.png Since the hour of the DST switch is chosen to minimize human activity, this won't be an issue for most websites. UIs that allow entering unambiguous datetimes in local time aren't intuitive — basically, you need an "is_dst" checkbox. If you really need to enter non-ambiguous data in local time during the DST switch, you probably shouldn't be working in local time at all. Armies use UTC, for instance. > A setting "ON_NAIVE_DATETIMES=[do_nothing|log|error]" could be nice, > at least for testing. This way you could spot the errors early on. I > don't know if that would be too expensive performance wise, though. > During the ambiguous hour, we have the choice between guessing randomly and raising an exception. The Zen of Python says: "In the face of ambiguity, refuse the temptation to guess." That said, you can use your own tzinfo implementations if you want to customize that behavior. > One idea is to use "SELECT col AT TIME ZONE 'GMT+2' as col". This way > the session time zone doesn't need to be changed. For example: > > SET TIME ZONE 'UTC'; > > create table testt(dt timestamptz); > > insert into testt values(now()); > > select dt at time zone 'GMT+2' as dt from testt; > 2011-11-18 07:06:47.834771 > > > select dt at time zone 'Europe/Helsinki' as dt from testt; > 2011-11-18 11:06:47.834771 > > Oracle seems to have a similar feature [1]. I don't know if other > databases offer similar functionality. MySQL has probably support for > something similar when using TIMESTAMP columns. > > But as said, I don't see this as a major issue. It would be nice to > support this some day. > This looks interesting, although I don't know how difficult it would be to integrate in the ORM. I'm going to create a ticket and post your research there. I hope to see this in trunk soon. > It is now :) -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Thank you!
This is the first framework I'm using that doesn't make me feel the urge to hack the framework's code in order to get something done. It just feels natural to extend stuff in the intended way. It took me ten days to learn the basics and build ~80% of a moderately complex project management system. Awesome! Keep up the good work! Danilo -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for review / Multiple time zone support for datetime representation
On Nov 18, 5:31 pm, Aymeric Augustin wrote: > Hi Anssi, > > 2011/11/18 Anssi Kääriäinen > > > So, at least according to this simple test there is nothing to > > worry about performance-wise. > > Thanks for the performance tests! They were still on my TODO list. The tests could be better... It might be worth it to write something testing this into djangobench. I just don't know which branch is the current one :) > If you're using aware datetimes internally, user input is the only source > of naive datetimes in local time. Ambiguous values are handled properly by > a validation error:http://myks.org/stuff/django-tz-demo-2.png My point is that it would be very useful to know you are actually using aware datetimes internally. Especially when migrating an old project to use this feature, it is easy to miss some places that do not use aware datetimes. And you might find it out when you hit an hour where suddenly your webapp is failing all over the place. So the setting I proposed would report usage of naive datetimes all the year, so that you could spot the problems in testing, not in production. > > One idea is to use "SELECT col AT TIME ZONE 'GMT+2' as col". This way > > the session time zone doesn't need to be changed. For example: > This looks interesting, although I don't know how difficult it would be to > integrate in the ORM. > > I'm going to create a ticket and post your research there. This is easy as far as writing the cast goes (a couple of lines in backend/operations should do the trick), the problem is that columns do not support parameters for the SQL, and fixing this will need to touch n+1 places. Although allowing column parameters would be useful in the long run even without the timezone problem. Aliasing the columns properly could be a problem, too. It could be possible to get rid of the SET TIME ZONE at the start of new connections completely. This would save a couple of network round trips for every connection. Although there might be some small backwards compatibility problems for users using raw SQL... > It is now :) Nice! And thank you! - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Request for review / Multiple time zone support for datetime representation
2011/11/18 Anssi Kääriäinen > My point is that it would be very useful to know you are actually > using aware datetimes internally. Especially when migrating an old > project to use this feature, it is easy to miss some places that do > not use aware datetimes. And you might find it out when you hit an > hour where suddenly your webapp is failing all over the place. So the > setting I proposed would report usage of naive datetimes all the year, > so that you could spot the problems in testing, not in production. > Ah, yes, that's an good point. It's very easy to intercept naive datetimes that reach the database adapter: https://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L788 I considered adding a warning there, but I decided against it because I thought it would be too obnoxious. This deserves further thought. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
