David Cramer wrote:
> If you're not doing denormalization in your database, most likely
> you're doing something wrong. I really like the approach that is
> offered here.
>
> For me, personally, it would be great if this could accept callables
> as well. So you could store the username, like so, or you could store
> a choices field like:
>
> field = models.IntegerField(choices=CHOICES)
> denorm = models.DenormField('self', 'get_field_display') # which
> would rock if it was .field.display ;)
>
> You could also make it somehow accept querysets or something similar
> for things like count(). I see a lot of possibilities and am a bit
> disappointed I didn't come up with something this easy for my use-
> cases.
>
The key is making sure you can listen for changes on whatever's at the
other end of your denormalisation. With my current snippet, it listens
for a save on the model the foreignkey points to, then checks for the
right ID; if we start accepting random querysets, then there has to be a
way to resolve that back to conditions the signal listener can understand.
Still, with an
AggregateField(Sandwiches.filter(filling="cheese").count()) it's still
possible to work out that you want to listen on the Sandwiches model,
and you could then fall back to re-running the count on every Sandwich
save, even if it ends up not having a cheese filling.
So, I think the best approach would be one to replicate fields (like my
current DenormField; perhaps call it CopyField or something) and one to
cache aggregates (an AggregateField, like above).
Simon Willison wrote:
> Just so it's on the record, I'd like any denormalisation tools in
> Django to include a mechanism for re-syncronizing them should
> something go awry (like direct updates being applied to the database
> without keeping the denormalised fields in sync). This mechanism could
> then be exposed as a ./manage.py command which could be called
> periodically to verify and fix any incorrect data.
Yes, this I very much agree with. The reason you always layer this stuff
on top of a pre-normalised database is because you can then rebuild the
data after playing with it externally.
Doing so shouldn't be too much of a problem; have a management command
that loads the models, and then just executes the update method on each
of the denormalisationalish fields.
Justin's idea of lazy updating is interesting, and probably quite doable
(as well as what most people will want by default on aggregate queries).
I'm also hoping any kind of aggregate denormalisation will work with any
future extended aggregate support, but if the field just takes a normal
QuerySet, that might Just Workâ˘.
Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
