rties..
In either case, the `data` and `files` attributes are set as they were before
which means they are still available just like before. Am I missing something?
Do you or Shai have a real example that would correct understanding?
On Jan 31, 2013, at 11:56 AM, Alex Ogier wrote:
> Byron,
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
>
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
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:
> >
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
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
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
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
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
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 out
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
permission should shadow its parent.
On Oct 19, 9:08 am, Byron wrote:
> Added ticket and patch:http://code.djangoproject.com/ticket/14492
>
> On Oct 17, 12:00 pm, Byron wrote:
>
>
>
>
>
>
>
> > I came across an issue when comparing a model proxy instance and a
>
Added ticket and patch: http://code.djangoproject.com/ticket/14492
On Oct 17, 12:00 pm, Byron wrote:
> I came across an issue when comparing a model proxy instance and a
> model instance, that is:
>
> obj1 = Entry.objects.get(id=1)
> obj2 = EntryProxy.objects.get(id=
I came across an issue when comparing a model proxy instance and a
model instance, that is:
obj1 = Entry.objects.get(id=1)
obj2 = EntryProxy.objects.get(id=1)
obj1 == obj2 # False
This I feel is a bug and the culprit is in ``Model.__eq__`` where it
tests to see if the object being co
o-newcache, at least.
>
> Thanks,
> Eric Florenzano
>
> On Aug 4, 11:31 am, Ned Batchelder wrote:
>
>
>
> > On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote:
>
> > > On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
>
> > >> Updated the patchhttp://code.dja
m, Jacob Kaplan-Moss wrote:
> On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote:
> > Updated the patchhttp://code.djangoproject.com/ticket/13795
>
> Looks good. A couple of questions/comments:
>
> * Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't
> qui
Updated the patch http://code.djangoproject.com/ticket/13795
On Jun 23, 11:12 am, Russell Keith-Magee
wrote:
> On Sun, Jun 20, 2010 at 6:16 AM, Byron wrote:
> > Yes I agree. I never quite understood why the
> > CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower
uments (and their defaults) to make the code cleaner.
>
> On Jun 19, 4:46 am, Byron wrote:
>
>
>
> > Opened a ticket and added my
> > patch..http://code.djangoproject.com/ticket/13795
>
> > On Jun 15, 7:15 pm, Giuseppe Ciotta wrote:
>
> > > On Wed, Jun
Opened a ticket and added my patch.. http://code.djangoproject.com/ticket/13795
On Jun 15, 7:15 pm, Giuseppe Ciotta wrote:
> On Wed, Jun 16, 2010 at 1:04 AM, Giuseppe Ciotta wrote:
> > On Wed, Jun 16, 2010 at 12:46 AM, Jeremy Dunck wrote:
> >> On Sun, Jun 13, 2010 at 7:18 AM, lenz wrote:
> >>>
7;s a pretty easy fix if the core team agrees that it's useful. Seems
> like the debate might be more around adding another setting for it/
> where/how to manage that prefix.
>
> All the best,
>
> - Gabriel
>
> On Jun 1, 8:12 am, Byron wrote:
>
>
>
> > I
ensuring there are no conflicts. Obviously if the
behavior is to share cache between projects, then no prefix can be
specified.
I want to get initial feedback, implications, etc. on this before I
start writing a patch.
Thanks,
-Byron
--
You received this message because you are subscribed to
22 matches
Mail list logo
