Hallöchen!
Tim Shaffer writes:
> [...]
>
> I think in both these cases (there is no person actually an
> instance of "Person", and there should be no actual instance of
> "Media"), it would be best to mark the parent class abstract and
> use a generic relation (like you said) to join to either MP3Media
> or WAVMedia. This is the "Django way" and I believe is the
> functionality you're looking for.
There is no need to mark it as "abstract". Besides, you lose the
possibility to link to it in ForeignKeys (which I need).
> [...]
>
> class Media(models.Model):
> filename = models.CharField(max_length=200)
> class Meta:
> abstract = True
>
> class MP3Media(Media):
> def play(self):
> print "playing mp3"
>
> def __unicode__(self):
> return self.filename
>
> class WAVMedia(Media):
> def play(self):
> print "playing wav"
>
> def __unicode__(self):
> return self.filename
>
> class Playlist(models.Model):
> name = models.CharField(max_length=200)
>
> class Song(models.Model):
> content_type = models.ForeignKey(ContentType)
> object_id = models.PositiveIntegerField()
> content_object = generic.GenericForeignKey() # WAVMedia or MP3Media
>
> playlist = models.ForeignKey(Playlist)
>
>>>> m = MP3Media(filename="test.mp3")
>>>> w = WAVMedia(filename="test.wav")
>>>> p = Playlist(name="My Songs")
>>>> p.song_set.create(content_object=w)
>>>> p.song_set.create(content_object=m)
>>>> for song in p.song_set.all():
> ... song.content_object.play()
> playing mp3
> playing wav
You may do so, but this is not particularly simple. Note that if
this was implemented in pure Python code, you wouldn't need any
"Song" class. You would just create a list and throw different
objects into it. Even in C++, where all elements in a list must
have the same base class, which is therefore closer to Django's
constraints, you wouldn't need "Song".
The root problem is that Django stores too little in parent
classes. It stores the primary key, that's all. Then, it looks in
child tables where it can find the primary key there too, and if so,
you get the actual instance.
I think Django should store the fully qualified class name of each
row in the parent table. For example, the "Person" table would have
a column with entries like "myapp.Author" or "myapp.Translator".
Then, a find_actual_instance method could be implemented both
reliably and efficiently.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
