Hi, guys!
For a long time I have thoughts to make composition/denormalisation a
little bit easier and reusable. But I have no time to implement my
ideas.
Inspired by Anrew's blog post and its thread I recently wrote some
code. And I think that it really may be useful and cover most of
denormalisation use cases in Django.
And this is an example of Anrew's code but with my CompositionField:
class Picture(models.model):
user = models.ForeignKey(User)
user_username = CompositionField(
native=models.CharField(max_length=150),
trigger=dict(
sender_model=User,
field_holder_getter=lambda user:
user.picture_set.all(),
do=lambda picture, user, signal:
user.username
)
)
image = models.ImageField(upload_to="foo")
title = models.CharField(max_length=100)
Its more verbose but very generic and can be customized. And free
bonus - auto-generated `update_user_username` method.
The code available here [1]. Its very generic but allows to write more
high-level subclasses with some introspection.
Today I've written the blog post about it and my future suggestions.
It is in Russian[2], here is a google-translated version [3] (but with
broken code blocks) that I think can help to understand some concepts.
And it holds more usage examples.
I have many new ideas of how my solution can be improved and I what to
hear you opinions about it.
Thanks.
[1]: http://svn.turbion.org/turbion/trunk/turbion/utils/composition.py
[2]: http://webnewage.org/post/2008/9/26/krasivaya-kompozitsiya/
[3]:
http://translate.google.com/translate?u=http%3A%2F%2Fwebnewage.org%2Fpost%2F2008%2F9%2F26%2Fkrasivaya-kompozitsiya%2F%23comment_720&hl=en&ie=UTF-8&sl=ru&tl=en
On Sep 23, 12:03 am, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> So, hello everyone. I figure this list is the best place to ask this,
> but please feel free to deride me if not...
>
> After all the talk of multiple databases, and non-relational databases
> (bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've
> been thinking about denormali[s/z]ation and how to make it easier in
> Django; previously, I had thought denormalisation was something you did
> to ruin your database, but I can now see it can be additive as well.
>
> In this vein, last weekend I decided to see how easy it would be to
> write a magical DenormalisationField which handled all the synchronising
> of data from the relevant tables given a normal ForeignKey relationship;
> the results are athttp://www.aeracode.org/2008/9/14/denormalisation-follies/
>
> Basically, yes, it is possible, and a lot of people (eight! for my blog,
> that's a lot) seem to like the idea; it certainly saves having to write
> that replicate-on-save logic that otherwise goes with this kind of
> schema design.
>
> Given the fact that it seems like a reasonably common thing to do in
> large-scale applications, I'd like to know what people think about
> adding this kind of thing into core (while I have a standalone
> implementation, that needs some hacks I'd like to see gone). My main
> issues with this idea are:
>
> 1) It relies on having a ForeignKey pointing to the other model, so this
> might not work for non-relational databases (well, unless ForeignKeys
> are still allowed in that case, but they just perform expensive SELECTs
> as well as possibly printing abusive messages to stderr).
>
> 2) I'm not sure how common a use case this is; it sounds like it might
> be verging into the long tail a bit.
>
> 3) People also want other things denormalised - count()s, aggregate
> queries, etc. Of course, writing fields for these too is similar, and
> I'd be happy to do it, but it might mean that even if the case for
> denormalisation is good this is only a piece of the puzzle.
>
> So, I'd love people's opinions about where I should take this - to a
> dark corner and hide it, to a separate app like django-extensions (which
> involves keeping the horrid hacks in there), into a separate app but
> with patches to core to make it less hackish (i.e. more signals), or add
> it as my 1.1 pony with the proviso that I'm happy to write all the code.
>
> 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
-~----------~----~----~----~------~----~------~--~---
