Martin Aspeli wrote: > Hi, > > This kind of works, but there are a few problems: > > - The 'owners' variable on the Game type only contains Vehicle > objects. I'd like it to contain the correct sub-class if possible.
When a row is received SQLAlchemy would need to know what type that row is, in order to dispatch to the correct class. SQLA currently uses a discriminator column for that purpose, so you'd have to find some way to have a column in the result set (or an expression) which can be used in this way. > > - I've had to repeat all the fields from the base class in the > sub-classes. Otherwise, I'd get errors using those attributes, even > though VehicleCar and VehicleBus both inherits form Vehicle. Well SQLA doesn't have any direct support for PG INHERITS, and the fact is that concrete inherits means that each Table repeats each common column specifically - one reason why concrete inheritance is widely considered to be the most cumbersome form of relational inheritance. There was a trac ticket requesting that the columns "inherit" the way they do with a simpler single- or joined- table setup, but at the end of the day that request was asking for some very complex magic to occur. Your database expresses distinct columns at the public DDL level, even though INHERITS means theyre the "same", so SQLA keeps it simple and would like you to express them in the same way as what it will see when talking to the DB. > > - Setting a 'backref' on the relation() on VehicleCar and VehicleBus > results in an error (the Owner object already has an 'owners' field) there is documentation on how to address concrete backrefs, using the "back_populates" keyword: http://www.sqlalchemy.org/docs/05/mappers.html#using-relations-with-inheritance > > I feel like I may've missed something here, though. Any suggestions on > how to do this better? unfortunately we haven't attempted to smoothly integrate with PG's INHERITS. It may or may not require additional complexity and would provide a feature that would not work on any of the other half dozen databases we support. My understanding is that INHERITS is usually used in practice to provide transparent "sharding" of table data and not necessarily to express class hierarchies, but this is strictly anecdotal knowledge. I'm actually encouraged that you've gotten it to work somewhat reasonably. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@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.
