I was just wondering.. Why all this abstraction? Why do we need a separate field for denormalization? Can't we just use regular fields and simply set up denormalization in a procedural way in the constructor? All that needs to be done to create a denormalized field is connect a few signals maybe or do some expensive compuation after modifying a field. But maybe I'm missing something crucial.
Erik On 26.09.2008, at 18:45, Alex Koshelev wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
