On Oct 30, 2011, at 4:19 PM, Jeremy Dunck wrote:
Hi Jeremy,
> I locally have a test-runner class that calls .clear() on setUp.
> Works for me. But we run CI, so test against prod. I needed to point
> to different CACHES under test to avoid flushing prod cache 20 times
> per day.
Right. You've
On Oct 29, 2011, at 11:14 AM, Aymeric Augustin wrote:
Thank Aymeric,
>
>> As an alternative, I propose we:
>>
>> 1. Add a new optional setting under CACHES, CLEAR_BETWEEN_TESTS. The default
>> for this setting is False. To be clear, the value is set independently for
>> each cache defined in
I noticed that Aymeric Augustin committed a patch last week [17042] that
fixed some issues in the cache backends. Apparently the fact that the cache
carries over test to test remains a problem.
I've progressed pretty far with an aggressive "fix" for this problem with
the patch in #11505. The
On Oct 21, 2011, at 8:04 AM, Kääriäinen Anssi wrote:
> I do not know nearly enough about caching to participate fully in this
> discussion. But it strikes me that the attempt to have CSRF protected
> anonymous page cached is not that smart. If you have an anonymous submittable
> form, why
On Oct 20, 2011, at 6:02 PM, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Jim,
>
> This is a really useful summary of the current state of things, thanks
> for putting it together.
>
> Re the anonymous/authenticated issue, CSRF token, and Google Analytics
>
On Oct 20, 2011, at 10:26 AM, Niran Babalola wrote:
> This problem is inherent to page caching. Workarounds to avoid varying
> by cookie for anonymous users are conceptually incorrect. If a single
> URL can give different responses depending on who's viewing it, then
> it varies by cookie.
I spent the better part of yesterday mucking around in the dregs of Django's
cache middleware and related modules, and in doing so I've come to the
conclusion that, due to an accumulation of hinderances and minor bugs, the
per-site and per-view caching mechanism are effectively broken for many
On Jul 14, 2011, at 1:31 AM, Simon Riggs wrote:
> On Sun, Jul 10, 2011 at 3:27 PM, Jim Dalton <jim.dal...@gmail.com> wrote:
>> On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
>>
>>> Maintaining the property of deferrable constraints seems important
>>&
On Jul 10, 2011, at 3:13 AM, Simon Riggs wrote:
> Maintaining the property of deferrable constraints seems important
> here, so changing the deferrability of constraints, or overriding it
> using the SET CONSTRAINTS command at the top of the transaction might
> not be what we want.
Well, that's
On Jul 4, 2011, at 8:01 AM, Jacob Kaplan-Moss wrote:
> On Mon, Jul 4, 2011 at 8:54 AM, Jim Dalton <jim.dal...@gmail.com> wrote:
>> I've created a ticket for this and uploaded a patch:
>> https://code.djangoproject.com/ticket/16401
>> Please feel free to review and le
I've created a ticket for this and uploaded a patch:
https://code.djangoproject.com/ticket/16401
Please feel free to review and let me know if this is a good idea in the first
place, as well as if the patch makes sense and is the right approach.
Thanks,
Jim
--
You received this message
Awesome feedback, thanks.
On Jul 1, 2011, at 10:01 AM, Jeremy Dunck wrote:
> Well, I think you forgot all the other low-level cache options, like
> .incr, .add, etc.?
Yep, forgot those so they would conceivably need to be tracked.
>
> If I were to do this, I wouldn't have cache shared between
On Jun 28, 2011, at 6:29 AM, Cal Leeming [Simplicity Media Ltd] wrote:
> Sorry for the noobish question but, could someone explain the definition of
> "forward references"?? Is this a MySQL or a django term?? Google wasn't very
> forthcoming :X
Jacob actually requested that I add a note in the
On Jun 28, 2011, at 6:25 AM, Karen Tracey wrote:
> It actually doesn't *need* to return False; pass is the same as not returning
> anything or returning None. The boolean check just treats it the same way as
> False. "Should it?" is another question. On the one hand it's a bit more
> clear,
On Jun 28, 2011, at 5:27 AM, Karen Tracey wrote:
> Also, though I don't have MySQL 4 handy to test on, I'd be astonished if
> there were any issue there compared to MySQL 5. The set foreign_key_check
> command is certainly supported in MySLQ 4 and the select being issued to do
> the check is
On Jun 27, 2011, at 5:44 PM, Michael Blume wrote:
> I see a variable saved_objects being written, but I don't see it being
> accessed -- is this to ease future features, or am I missing a code path?
Thanks good catch. This was a remnant from an earlier iteration of this patch,
in which I tried
On Jun 27, 2011, at 4:52 PM, Russell Keith-Magee wrote:
> Unfortunately, not much. Your test has validated that the extra code
> doesn't break anything under MyISAM, and this is certainly useful.
> However, the root problem only exists with InnoDB because of its...
> eclectic... implementation of
I've been trying to do a little work recently on some tickets that related
to MySQL-specific issues that come up using Django (#2495 and #3615
specifically). As part of trying to get my head around resolving these, I
executed the test suite in the current Django trunk using a MySQL InnoDB
18 matches
Mail list logo
