I'm going to be updating the project page with as much bad English as
I can possibly write :)
If anyone else is interested in contributing the project please let me
know.
On Dec 19, 8:33 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Here's the IRC chat from today:
>
> Most useful bits:
>
>
IRC would be good -- I'm always in the Django channel while at work
(dcramer, dcramer_, zeeg, or zinor).
But yes, you are correct. We don't care if d is added until it's
expired. With model or object dependancy though, that could be
handled.
On Dec 13, 10:16 am, "Jeremy Dunck" <[EMAIL
On Dec 13, 2007 1:16 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> ...Perhaps IRC or chat would be good here?
Just make sure you post the results of said chat so the rest of us can see. :)
-Gul
--~--~-~--~~~---~--~~
You received this message because you are
On Dec 13, 2007 11:14 AM, David Cramer <[EMAIL PROTECTED]> wrote:
...
> > Since inserts are undetected by the cache in the basic proposal, are
> > you accepting only short timeouts? I imagine with your traffic, even
> > small windows of caching have big benefits. I guess the per-manager
> >
> > We briefly discussed adding row-level dependencies (this key is
> > dependent on x, y and z keys. It would be handled by storing an extra
> > object in memory that stored the dependencies for the object. A simple
> > reverse mapping if you will.
>
> The intention here would be to handle
On Dec 8, 2007 10:29 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> We briefly discussed adding row-level dependencies (this key is
> dependent on x, y and z keys. It would be handled by storing an extra
> object in memory that stored the dependencies for the object. A simple
> reverse mapping
We briefly discussed adding row-level dependencies (this key is
dependent on x, y and z keys. It would be handled by storing an extra
object in memory that stored the dependencies for the object. A simple
reverse mapping if you will.
e.g.
- articles_article:1 has the object cache for the
On 12/7/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> > FWIW, I'm interested in this approach.
>
> Same here. I'm planning to look at this on Monday, but am very much
> interested.
I haven't given any thought to how caching should work internally, but
this approach seems on par with how the
On Dec 7, 2007 6:07 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> FWIW, I'm interested in this approach.
>
> I haven't had time to poke at the design, but wanted to at least give
> some indication of interest since the thread's been quiet.
Same here. I'm planning to look at this on Monday,
FWIW, I'm interested in this approach.
I haven't had time to poke at the design, but wanted to at least give
some indication of interest since the thread's been quiet.
On Dec 6, 2007 4:46 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> read this first:
>
Here's some code that's been started -- I know you're interested in
this Adrian :)
http://www.pastethat.com/?weBZo
This pulls in 2 different things that we've worked on:
CachedForeignKey (little bits of it), and CacheManager (which is what
brings in CachedQuerySet as well).
This is just a
read this first:
http://www.davidcramer.net/code/61/handling-cache-invalidation.html
The goal is to create a cachedmodel, which relies on a completely
different set of routines. All calls to this model, whether it be a
foreignkey lookup, an objects call, or a JOIN on it's table (inside
the
12 matches
Mail list logo
