> > if u have different attributes for different Content subtypes, > > then that means subclasses and eventualy polymorphism. Or u go > > the single_typee (singletable) way, and put all stuff in Content, > > and just check for presence/absence of some attributes. > > yep I have different attributes for different content subtype, for > example I have a class Event(Content), a class News(Content), ... > and three SQL tables : contents(id pk), events(content_id pk and > fk), news(content_id pk and fk) > etc etc > > as Mike suggested I will add a table content_types to avoid to many > queries, so I could to: > for p in Parent.Select(): > if p.content_type.name == "news": > foo = News.get(p.content_id) > # do stuff > elif p.content_type.name == "event": > bar = Event.get(p.content_id) > # do stuff >
so this is the polymorhism done in python and not in SQL... i notice a pattern here (3 times last 2 weeks or so), may eventualy be mentioned/suggested in the docs about polymorphism? hmm, just suggestion, u could do it both ways, one sql-polymorphic and one python-polymorphic (u have all data needed - the type column), via 2 mappers (e.g. the sql-polymorphic one being secondary), and use either one depending on use case/size/quick-and-dirty/whatever.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
