building SQLAlchemy apps graphically, that's extremely challenging good luck !
On May 1, 2012, at 5:19 AM, lars van gemerden wrote: > 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. > -- 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.
