Hi Michael,
Thanks for the quick reply!
Michael Bayer wrote:
> 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.
How would the mapper configuration look if it were an expression? If it
were a column?
>> - 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.
True, except I think it's superflos. I could do this in Postgres too:
CREATE TABLE vehicle (
id integer NOT NULL,
owner_id integer,
price integer
);
CREATE TABLE vehicle_car (
fuel_type integer
)
INHERITS (vehicle);
CREATE TABLE vehicle_bus (
passengers integer
)
INHERITS (vehicle);
vehicle_car and vehicle_bus now implicitly get columns id, owner_id and
price from the base table, as their first columns.
>> - 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
Thanks for the pointer! I think I need to read that a few more times. :)
>> 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.
Maybe just by luck? :)
We've inherited this schema. I had to look up the keyword in the
Postgres documentation, as I'd never heard of it before. It's kind of
neat, and has some uses in our application, but it's also fairly
esoteric, I guess.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
--
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.
