27 messages in com.googlegroups.sqlalchemy[sqlalchemy] Re: polymorphic mapping ...
FromSent OnAttachments
svilen24 Jan 2007 06:02.py
svilen25 Jan 2007 00:20 
svilen25 Jan 2007 00:50 
sdob...@sistechnology.com27 Jan 2007 08:53 
Michael Bayer27 Jan 2007 11:40 
Michael Bayer27 Jan 2007 12:31 
Michael Bayer27 Jan 2007 17:32 
sdob...@sistechnology.com28 Jan 2007 08:16.tbz, .py
Michael Bayer28 Jan 2007 11:56 
sdob...@sistechnology.com28 Jan 2007 12:54 
Michael Bayer28 Jan 2007 13:57 
svilen29 Jan 2007 01:39 
svilen29 Jan 2007 10:41.py, .py
Michael Bayer29 Jan 2007 11:14 
Michael Bayer29 Jan 2007 11:18 
svilen29 Jan 2007 11:41.py, .py
Michael Bayer29 Jan 2007 13:12 
Michael Bayer29 Jan 2007 13:39 
sdob...@sistechnology.com29 Jan 2007 15:26.py, .py
sdob...@sistechnology.com29 Jan 2007 15:48 
sdob...@sistechnology.com30 Jan 2007 00:50.py
svilen30 Jan 2007 01:40.py, .py
Michael Bayer30 Jan 2007 07:09 
sdob...@sistechnology.com30 Jan 2007 12:02 
svilen31 Jan 2007 09:42.py
Michael Bayer31 Jan 2007 11:17 
sdob...@sistechnology.com31 Jan 2007 13:57 
Subject:[sqlalchemy] Re: polymorphic mapping with more than 2 level of inheritance
From:Michael Bayer (mike@zzzcomputing.com)
Date:01/28/2007 11:56:23 AM
List:com.googlegroups.sqlalchemy

all tests pass with rev 2267 of that branch. try that rev specifically, since i want to take whats there and do another pass. im trying to get it so that the entire science of "parent table, child table, polymorphic selectables, primary join -> polymorphic joins -> determine direction/lazy clause/eager clause/synchronize FKs" is super-well-nailed down.

On Jan 28, 2007, at 11:16 AM, sdob@sistechnology.com wrote:

So, ive been working on this crapola pretty much all day.......

WAW! hey, don't overdose...

.... (YOURE WELCOME) ...

Hhmm. i don't believe in virtual beers, so maybe, treat you with this? http://www.giovannisample.com/media/mondo/Mondovision640.zip

and the latest is in a branch http://svn.sqlalchemy.org/sqlalchemy/ branches/polymorphic_relations .

i'll test how far it goes... quick test: This one fails some of the AB_all cases (the trunk passes them all - total 139). All failures are of same kind - the inheriting mapper (B) does not load some of it's references. i think there was similar error before and u did fix it then. see attachments (run "sa_ref_A_B_A_all.py eager generate_many failed_only" to get them all as sep.files)

i'll check more on how A,B,C behaves.

so, the one thing i really cannot crack at all is how to make polymorphic_union figure out the dupe "id" column in:

table_Employee.join(table_Engineer).select(table_Employee.c.atype == 'Engineer'),

since the embedded list of columns comes out only at compilation time for the query. so i think i want to look into modifying Select() to detect this internally and just raise an error. you cant say "use_labels" on this particular query either because polymorphic_union needs the real column names in order to determine the names for the union.

all you have to say is:

select([table_Employee, table_Engineer.c.machine], table_Employee.c.atype == 'Engineer', from_obj=[table_Employee.join(table_Engineer)]),

and it works, since you manually construct a column list that doesnt contain a dupe.

u mean to put the explicit-column select() instead of polumuion's entry for Engineer? okay i'll try this approach...

<poly-branch-fails.tbz> <sa_gentestbase.py>