th valid data when there is any. Your
> new method will bypass their customizations.
>
> Best,
> Alex Ogier
>
>
> On Thu, Jan 31, 2013 at 8:51 AM, Byron Ruth <bjr...@gmail.com> wrote:
> I don't understand your argument regarding overriding `__init__`. Nothing has
&g
),
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
> >
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,
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:
> >
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
Ticket opened for documentation: https://code.djangoproject.com/ticket/17236
On Nov 15, 3:35 pm, Byron Ruth <bjr...@gmail.com> wrote:
> Indeed, all of the settings are slowly becoming unwieldy. I will write
> my own `login()` function in the meantime, but the docs should
> defin
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 <bjr...@gmail.com> wrote:
> Posted original on the Django Users group because I thought I was
> missing
> something:http://groups.google.c
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
> 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
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
10 matches
Mail list logo
