[sqlalchemy] Re: references to polymorphic concrete-inheritance - svilen - com.googlegroups.sqlalchemy

5 messages in com.googlegroups.sqlalchemy[sqlalchemy] Re: references to polymo...

From	Sent On	Attachments
svilen	21 Feb 2007 07:05
Michael Bayer	21 Feb 2007 07:54
sdob...@sistechnology.com	21 Feb 2007 12:01
Michael Bayer	21 Feb 2007 15:15
svilen	22 Feb 2007 03:15

Subject:	[sqlalchemy] Re: references to polymorphic concrete-inheritance
From:	svilen (sdob...@sistechnology.com)
Date:	02/22/2007 03:15:09 AM
List:	com.googlegroups.sqlalchemy

FYI, polymorphic associations to concrete mappings are totally unsupported in Hibernate, an ORM that has a lot more maturity, widespread usage, and developers on it than this one...leaving me fairly uninspired to worry much about SA's similar limitations with polymorphic concrete mappings (even though SA has a better chance of supporting them, since we support mappings to unions).

http://www.hibernate.org/hib_docs/reference/en/html/ inheritance.html#inheritance-strategies

concrete mappings and A->B->C->D inheritance doesnt strike me as very high priority at this point....what im becoming interested in from hibernate at this point is its ability to issue multiple SELECTs for one query, for polymorphic loading as well as immediate relationship loading. thats of more generalized usage than SA's reliance upon UNION and elaborate LEFT OUTER JOINs.

that's all ok, i don't want u to do it, i want to know a how it can be done - if i ever need it. Anyway i cannot use concrete polymorphic stuff now, so i don't use it. But i do use table-inheritance, and there are some things there that do not work - or at least the way i'm using SA does not work. See the other mail about lazy-reference to polymorphic mappers; seems to me the select issued for lazy-load is wrong:

SELECT pu_b.db_id AS pu_b_db_id, pu_b.name AS pu_b_name, pu_b."linkA_id" AS "pu_b_linkA_id", pu_b.atype AS pu_b_atype, pu_b."dataC" AS "pu_b_dataC", pu_b."dataB" AS "pu_b_dataB" FROM ( SELECT "C".db_id AS db_id, "A".name AS name, "A"."linkA_id" AS "linkA_id", "A".atype AS atype, "C"."dataC" AS "dataC", "B"."dataB" AS "dataB" FROM "A" JOIN "B" ON "B".db_id = "A".db_id JOIN "C" ON "C".db_id = "B".db_id UNION ALL SELECT "bz4B".db_id AS db_id, "bz4B".name AS name, "bz4B"."linkA_id" AS "linkA_id", "bz4B".atype AS atype, CAST(NULL AS TEXT) AS "dataC", "bz4B"."dataB" AS "dataB" FROM ( SELECT "A"."linkA_id" AS "linkA_id", "A".name AS name, "A".db_id AS db_id, "A".atype AS atype, "B"."dataB" AS "dataB" FROM "A" JOIN "B" ON "B".db_id = "A".db_id WHERE "A".atype = ? ) AS "bz4B" ) AS pu_b WHERE pu_b."linkA_id" = pu_b.db_id ORDER BY pu_b.oid

IMO the last WHERE would need a second FROM entry but it has only one??

On Feb 21, 2007, at 3:02 PM, sdob...@sistechnology.com wrote:

id use an association table with its own entity to make things easy.

hm, u mean... A.link references that table by single id, and the table contains the tuple (discriminator,id) ? But isn't this another sort of table-inheritance? looks like a join to me... not that i'm big specialist on joins. And how to automate the secondary loadby(discriminator,id)?

On Feb 21, 2007, at 10:05 AM, svilen wrote:

g'day.

How one can make such thing as a reference to concrete-inherited polymorphic mapper? e.g. if there are just two, A and B, B inherits A, both have full concrete tables. A has polymorphic mapper.

If both tables have separate primary ids, they will overlap as values - table_A.id=1 for some A() and table_B.id=1 for some B() are both ok; hence, query(A).getby_id(1) would return 2 objects via the polymorphic union. in this case, the unique key within the polymunion seems to be the id+type_discriminator; where type_discriminator effectively means "this id is from that table".

i see 2 possibilities here:

- use 2-field key: a tuple of discriminator(table_name) and id-in-that-table. How would one make references to those objects then? e.g. what would be the definition of Column( 'mylink_id', ...) be ? it becomes a link to multiple tables... Would the propertyLoaders support such multi-column key? or make some constructed single key instead?

- use one common sequence for filling both primary-keys of both tables. But this is limited to DBs which support sequences...

Any help?

ciao svil