Posted original on the Django Users group because I thought I was
missing something:
http://groups.google.com/group/django-users/browse_thread/thread/a612987d2c3487e4
Per what Tom mentions on the Django Users thread:
- an authenticated user logging in under a different account keeps the
session
Here is the relevant code:
https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L63-70
On Nov 15, 1:44 pm, Byron Ruth wrote:
> Posted original on the Django Users group because I thought I was
> missing
> something:http://groups.google.com/group/dja
Indeed, all of the settings are slowly becoming unwieldy. I will write
my own `login()` function in the meantime, but the docs should
definitely be update to note this behavior.
On Nov 15, 2:27 pm, ptone wrote:
> On Nov 15, 10:44 am, Byron Ruth wrote:
>
>
>
> > How would e
Ticket opened for documentation: https://code.djangoproject.com/ticket/17236
On Nov 15, 3:35 pm, Byron Ruth wrote:
> Indeed, all of the settings are slowly becoming unwieldy. I will write
> my own `login()` function in the meantime, but the docs should
> definitely be update to
My use case is for regenerating aggregate data cache at a table level.
Simply calling a single signal after a bulk operation is complete would
enable invalidating such aggregate cache. There is not a very clean
alternate solution to this problem unless using database triggers which
calls an ext
l
> strongly at all about this, just
> something I would find useful. I believe having total control of all data
> modifying operations using Django
> signals would be a welcome addition for many users.
>
> - Anssi
> ____
> From: dja
existing signals
over would follow the normal deprecation policy. But it could be introduced
for the bulk-level operations initially without breaking any compatibility.
On Monday, March 26, 2012 4:00:14 AM UTC-4, Anssi Kääriäinen wrote:
>
> On 03/26/2012 06:34 AM, Byron Ruth wrote:
> >
Here is the ticket: https://code.djangoproject.com/ticket/19668 and the
pull request https://github.com/django/django/pull/674
One user commented on the ticket raising a concern that it could possibly
be misused if the data is set after it had been used. It is certainly a
valid concern, however
time),
you still need (are expected) to call `super` to _finish_ initialization.
On Thursday, January 31, 2013 1:08:52 AM UTC-5, Shai Berger wrote:
>
> On Thursday 31 January 2013, Byron Ruth wrote:
> > Here is the ticket: https://code.djangoproject.com/ticket/19668 and the
>
re is any. Your
> new method will bypass their customizations.
>
> Best,
> Alex Ogier
>
>
> On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth wrote:
> I don't understand your argument regarding overriding `__init__`. Nothing has
> changed in __init__, the logic for set
I am speaking of this particular if statement:
http://code.djangoproject.com/browser/django/tags/releases/1.2.4/django/db/models/sql/query.py#L1051
There are a few implications of this assumption. One being, that if
the user is actually trying to get the "real" rows that exist with a
column that h
> Just to be clear: The assumption is that if:
> 1) the user filtered on a related model's field
> 2) with is_null=True, and
> 3) there is a nullable FK in the chain leading to the filtered field
> (this is checked by promote_alias_chain),
> then:
> use a left out
12 matches
Mail list logo
