The code referenced in the above post:
@declared_attr
def __mapper_args__(cls):
if not has_inherited_table(cls):
return {'polymorphic_on': 'discriminator'}
else:
return {'polymorphic_identity': cls.__name__}
has broken between 0.7.9 and 0.8.0, now that __mapper_args__ is a lambda.
The call to has_inherited_table will always return true because mapper_args
are evaluated after everything is configured, so the first class in
cls__mro__ (which will be class) will now have a table attached to it,
while in 0.7.9, the mapper_args would be evaluated during as_declarative
and the table would not be present.
Is there a new way to accomplish the same thing?
On Tuesday, May 1, 2012 7:15:20 AM UTC-7, Michael Bayer wrote:
>
> 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]<javascript:>.
>
> >>> To unsubscribe from this group, send email to
> [email protected] <javascript:>.
> >>> 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]<javascript:>.
>
> > To unsubscribe from this group, send email to
> [email protected] <javascript:>.
> > 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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
