On Apr 17, 2012, at 6:25 PM, Amos wrote:
> The problems creep in when you "mix" the mixin and the inheritance
> functionality. The primaryjoin gotcha was the first hiccup, but now
> I'm having trouble re-using the Mixin class on a second derived model:
>
> ArgumentError: Column 'target_id' on class <class
> 'uber.model.test.Manager'> conflicts with existing column
> 'person.target_id'
Well yeah, that's why the overall pattern you're doing here is a little bit
ill-advised. Again this has nothing to do with the mixin, only with having
two separate "target_id" columns, you get the same result if you put target_id
on Manager and Engineer directly.
What if Engineer and Manager had different notions of "target_id" ? Should
declarative look at both columns, compare them and ensure they have the exact
same datatype and constraints, else raise an error ? Maybe. Though that feels
a little heavy handed.
I know it would be nice for the ORM modeling to work in a pure way but in this
kind of case the realities of the relational model have to be considered -
which is that single table inheritance defines the table persistence in terms
of the base class. You can model this as separate from Person, using an
intermediary class, so this is close:
class PersonWithTarget(Person):
target_id = Column(Integer, ForeignKey('target.id'))
target = relationship("Target",
primaryjoin="PersonWithTarget.target_id==Target.id")
class Engineer(PersonWithTarget):
pass
class Manager(PersonWithTarget):
pass
the above however is specific to single table inheritance - PersonWithTarget
here is mapped, but since you never use instance of it directly it doesn't
impact the database. This same model wouldn't work with joined-inheritance,
because it would want to build a "person_with_target" table in between Person
and Engineer/Manager. Ideally, PersonWithTarget should accept the
__abstract__ flag, meaning "don't map this class", but currently declarative
can't quite handle the __abstract__ class in the middle of the
single-inheritance scheme.
Anyway there's bits of a use case here, but the workarounds are pretty
straightforward so I wouldn't consider this very high priority.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
