How would generic relations solve this problem, It has been recommend for me to look at it a few times but I can't seem to understand how it would work.
Vitaly Babiy On Sat, Mar 7, 2009 at 7:50 AM, Tim Chase <django.us...@tim.thechases.com>wrote: > > >> class Tracker(models.Model): > >> notifications = models.ForeignKey(Notification) > >> > >> class Notification(models.Model): > >> # Common fields > >> pass > >> > >> class EmailNotification(Notification): > >> pass > >> > >> class SmsNotification(Notification): > >> pass > >> > >> > >> # I would be able to iterate over all types of notification > >> for n in tracker.notifications: > >> print n > > > > Not trivially, purely in SQL, at the moment. You really need to union > > two sets of results together, since they're querying different tables. > > Lots of history here, but basically, it's a hard problem to solve > > efficiently. One day we might do it. > > If one is willing to be roped to PostgreSQL, it does support such > a scheme with table-inheritance. You'd have to hack the table > definitions by hand instead of letting "manage.py syncdb" do it > for you. Additionally, Django's ORM knows nothing about this DB > hack, so virtual methods won't work like one might hope: > > class Notification(models.Model): > def __unicode__(self): > return u"Generic notification:" % self.common_field > class EmailNotification(Notification): > def __unicode__(self): > return u"Email: %s" % self.some_email_field > class SMSNotification(Notification): > def __unicode__(self): > return u"SMS: %s" % self.some_sms_field > > for n in tracker.notifications: > print unicode(s) > > You'll end up with every item being treated as a Notification > object (and thus printing "Generic notification" for all of > them), rather than getting the notification-specific methods. > > > On the other hand, since querysets are iterators, you can construct two > > querysets and then use itertools.chain to combine them and have it > > appears as a single iterator. > > A slightly less DRY solution than ideal (ideal=solving the VERY > complex STI problem in Django's ORM), but more portable across > database back-ends, less fragile, and available out of the box. > > Another alternative might be using Django's built-in generic > relations. > > -tim > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
