ORM Cache -- CachedModel

[David Cramer]

So it seems I'm finally to the point of where the code is working as
intended, at least for the initial phase.

Anyways, I had some weird quirks, and I don't know Django internals as
well as I'd like. I'd like to request anyone interested in the
project, or with some spare time, take a quick glance over the code
(ignoring file structure, as that will probably change).

A valid test case would be: (the queries are only accurate if you have
a reasonable cache expiration, one which wouldn't cause them to expire
within the time it takes you to execute the commands)

class MyModel(CachedModel): [...]

MyModel.objects.create(name="Test") [1 query]

MyModel.objects.all() [1 query ]
[Test,]

MyModel.objects.create(name="Test2") [1 query]

MyModel.objects.all() [no queries]
[Test,]

MyModel.objects.create(name="Test3") [1 query]

MyModel.objects.all().reset() [1 query]
[Test, Test2, Test3]

MyModel.objects.get(name="Test2").delete() [1 query]

MyModel.objects.all() [2 queries]
[Test, Test3]

[David Cramer]

Project link is probably useful: http://code.google.com/p/django-orm-cache/
:)

[David Cramer]

In fact, here's a shinier post with updated tests:

http://www.davidcramer.net/code/73/caching-layer-for-django-orm.html

[Jeremy Dunck]

On Jan 21, 2008 4:10 PM, David Cramer <dcr...@gmail.com> wrote:
>
> So it seems I'm finally to the point of where the code is working as
> intended, at least for the initial phase.
>

Definitely going to test this locally.

We use admin; I guess we can just make Admin.objects = Manager() to
get the uncached version?

[David Cramer]

You can either use MyModel.nocache, or use MyModel._default_manager (I
had been using the latter)

On Jan 21, 6:09 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote:

[David Cramer]

Some notes I shoved into a commit today:

# Signals rundown:
# .cache(expire_on=['create', 'update', 'delete'])
# use namespaces possible so the cache key becomes
key_name:expire_namespace(not always present):hash

# for example, a call with no expires:
# db_table:hash

# a call with a delete expires
# db_table:0,0,0:hash

# the numbers represent our current namespace level for the 3
expiration methods
# in order to do this, we'd have to actually store another cache key
per model
# and to support threading, query that cache key everytime we do any
cache queryset
# hit
# e.g. cache.get('ns:db_table') = 0,0,0

# when a new row is created, we'd set that to 1,0,0
# which would invalidate anything that had a create expiration set
because the key is
# now invalid, because the namespace changed.

# We can also add a table namespace, which says "delete everything" so
our
# cache key now becomes db_table:ns_count:0,0,0:hash
# where the 0,0,0: is optional

# ns_count would be stored in the same ns:db_table key and starts at 0
# this would most likely only be incremented if you did a push to your
site
# and needed to say wipe all articles because the dataset changed.

If you understand by gibberish, tell me what you think

[Jeremy Dunck]

On Jan 23, 2008 7:35 PM, David Cramer <dcr...@gmail.com> wrote:
>
> Some notes I shoved into a commit today:

...

>
> If you understand by gibberish, tell me what you think

I don't understand that gibberish, but am starting to poke at the code a bit.

Quick question on CacheManager.clean's comment: # Use reset instead if
you are using memcached

Why not just have clean check if the cache backend is memcache, and if
so, call reset rather than doing the normal clean stuff?

Separately, I'm currently admin on the google code project. Just to
be clear, are you comfortable with me committing there?

[David Cramer]

Yep, commit if you see something that you think is worthwhile. Most of
my commits are random gibberish notes.

In regards to clean. The originaly concept was it would delete the
cache key, reset would refresh it. With memcache you don't need to
delete them for the most part. The methods/organization behind it
could use a 2nd opinion though.

On Jan 25, 10:19 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote: