I need some sort of GenericForeignKey thing by the end of the week, and will be getting paid to work on it. I'll go either the subclassing route or the GenericForeignKey route, whatever is easiest. Let me know if you need a hand
On 9/26/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > > Jason Davies wrote: > > Robert Wittams wrote: > > > > [snip] > > > > > >>The other form of subtyping - ( ie is-a relationship) available, is the > >>one-to-one field. This makes a set of fields an extension to another > >>object. The way this is generated in django is to add > >>get_<extension_type_name> to each instance of the supertype. A base type > >>can have any combination of extensions. > >> > >> > >>I would suggest that the second type of subtyping is a more natural fit > >>for python inheritance of model classes. > > > > > > [snip] > > > > That sounds like a good solution. Preserving the semantics of Python's > > subclassing is important so that things are intuitive and work as > > expected. > > > > Would this have any bearing on solving ticket #529 (GenericForeignKey)? > > > > An aside: will we still break backwards compatibility after milestone > > 1.0? > > > > Jason > > > > > > Well GenericForeignKey is (imo) not necessary with 'real' subclassing. > It means that you would just do (for comments on a contrived horse > trading site): > > class Comment(meta.Model): > ...... subject, text, date, etc ... > > class CommentReply(Comment): > parent = meta.ForeignKey(Comment) > > class HorseComment(Comment): > parent = meta.ForeignKey(Horse) > > class TrainerComment(meta.Modl): > parent = meta.ForeignKey(Trainer) > > > This of course means more tables, but I can't see that that is a problem > with any modern database. > > -- Paul Bowsher IT Systems Developer Simply Stuck Ltd
