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.
+1 from me!
On Sep 22, 7:00 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Sep 23, 12:21 am, "Justin Fagnani" <[EMAIL PROTECTED]>
> wrote:
>
> > In my experience at least, denormalization occurs
> > a lot and leaves a lot of room for mistakes, so it's something a
> > framework should handle if possible.
>
> 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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
