Well thats the thing, my users will determine the data structure (graphically) and it is hard to predict what they will come up with. On the other hand, I am only building a prototype at the moment, so speed issues (if not easily solved) will have to wait.
I'll stick with joined inheritance for now (though I'll probalby take out the unique base class for all classes). Thank you again for all the help, Lars On Apr 27, 3:59 pm, Michael Bayer <[email protected]> wrote: > concrete inheritance is very challenging overall, if you expect there to be > any kind of polymorphic interaction between the classes. if you want to > query polymorphically then speed will be probably worse. If you can do > without polymorphic and stick to each subclass directly it wont have an issue. > > Usually though if I'm inheriting more than two levels, I'll use joined > inheritance for level one->two then single table for all levels beyond that. > Depends on what you're trying to do. > > On Apr 27, 2012, at 3:05 AM, lars van gemerden wrote: > > > > > > > > > Ok, so speed might become an issue for me as well; > > > Do you think a similar metaclass approach would work for concrete > > inheritance would work without major drawbacks (before i do a major > > overhaul)? > > Is there any indication about how much faster concrete inheritance is, > > compared to joined inheritance? > > > Cheers, Lars > > > On Friday, April 20, 2012 9:32:49 PM UTC+2, Michael Bayer wrote: > > > On Apr 20, 2012, at 8:51 AM, lars van gemerden wrote: > > > Ok, thank you, that helps, but now i cannot inherit from Engineer, as in: > > > > class BaseMixin(object): > > > > discriminator = Column(String(50)) > > > > @declared_attr > > > def __tablename__(cls): > > > return cls.__name__ > > > @declared_attr > > > def id(cls): > > > return Column(Integer, primary_key = True) > > > @declared_attr > > > def __mapper_args__(cls): > > > if not has_inherited_table(cls): > > > return {'polymorphic_on': 'discriminator'} > > > else: > > > return {'polymorphic_identity': cls.__name__} > > > > class InheritMixin(BaseMixin): > > > @declared_attr > > > def id(cls): > > > super_id = super(InheritMixin, cls).id > > > return Column(Integer, ForeignKey(super_id), primary_key = True) > > > > class Person(BaseMixin, Base): > > > name = Column(String(50)) > > > > class Engineer(InheritMixin, Person): > > > job = Column(String(50)) > > > > class MasterEngineer(InheritMixin, Engineer): > > > specialty = Column(String(50)) > > > > Gives an MRO() error and if i would reverse the baseclasses (like class > > > Engineer(Person, InheritMixin): ... ), the inheriting classes pick up > > > the wrong id. > > > > Do you see any solution for this? > > > yeah I suppose if you're building out joined inheritance more than one > > level then this becomes awkward. I never use joined inh more than one > > level because it has too much of an impact on queries. > > > the metaclass as you mention is always the last resort when the various > > declarative trickery reaches its limit. I'm not thrilled about the > > metaclass approach because it quickly gets confusing and shouldn't be > > necessary. though in this case without some extra mechanism on > > declarative, such as a __pre_declare__() method of some kind, it might be > > the only approach. > > > -- > > You received this message because you are subscribed to the Google Groups > > "sqlalchemy" group. > > To view this discussion on the web > > visithttps://groups.google.com/d/msg/sqlalchemy/-/MH4tZazKT0EJ. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
