[sqlalchemy] Re: Concrete inheritance woes
On Mon, Apr 28, 2008 at 10:33 PM, Michael Bayer
[EMAIL PROTECTED] wrote:
pjoin = polymorphic_union(...)
pjoin2 = polymorphic_union(...)
employee_mapper = mapper(Employee, pjoin, polymorphic_on=pjoin.c.type)
manager_mapper = mapper(Manager, managers_table,
inherits=employee_mapper, concrete=True, polymorphic_identity='manager')
engineer_mapper = mapper(Engineer, engineers_table,
with_polymorphic=('*', pjoin2),
polymorphic_on=pjoin2.c.type,
inherits=employee_mapper, concrete=True,
polymorphic_identity='engineer')
hacker_mapper = mapper(Hacker, hackers_table, inherits=engineer_mapper,
concrete=True, polymorphic_identity='hacker')
This solves nicely my multi-level problem, thanks !
this should in theory also fix the engineers relation on Company.
Doesn't seem to. Since I guess it's a bug, I've filed ticket 1018 for this.
http://www.sqlalchemy.org/trac/ticket/1018
But as I've said many times (to svil, at least) concrete inheritance
is something i havent gotten into much as of yet, largely due to the
many inherent issues with it as well as its being a generally
unpopular pattern, so there may still be issues with this setup (but
let me know, since thats how it should work).
Ok, no worries.
In any case the unit tests which you were working from (im guessing
test/orm/inheritance/concrete.py) should be patched to include this
test (i.e. including Hacker, the polymorphic load, as well as the
relation).
I'll add the working multi-level test this afternoon. I guess you
don't want the relation part yet.
Assuming it works we should also make sure the 0.5 branch
(which isnt called that yet) can handle it too.
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Tue, Apr 29, 2008 at 12:11 PM, Gaetan de Menten [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 10:33 PM, Michael Bayer [EMAIL PROTECTED] wrote: In any case the unit tests which you were working from (im guessing test/orm/inheritance/concrete.py) should be patched to include this test (i.e. including Hacker, the polymorphic load, as well as the relation). I'll add the working multi-level test this afternoon. Done. -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
g'day Gaetan u could try my tests and play with DB_inheritance=concrete to see my experience so far with dbcook (not documented i know but works4me) and its tests. also u can look up the mailgroup history for my own concrete-related complaints... most of them have hit unimplemented parts of SA so they stopped there. codewise, see mapcontext.py and mapper-stuff in builder.py. Most of logic is about whether an object is being split into tables (joined) or not (concrete). i also have mixed inheritance (parts of the hierarchy this way, part another, then again), but thats even further the track. IMO should work once the pure concrete is ok. btw did u get single inh to work 100%? i didnt bother to finish it... no time/usecase. i guess some of the things might have cleared since recent introduction of with_polymorphic, but i havent tried really... dbcook is still using select_table so needs some rework. hmm as i see current SA trunk does not work now with exactly some concrete tests, and some other issues of me using under-cover things. as a rough guess, v4300 seems to work. ./dbcook/tests$ make abc will do all inheritances, AB only, ~200 cases, no C-level. ok on v4300; 3 fails (inh=c) on recent trunk ./dbcook/tests$ make abcj will do joined inh, A+B+C, ~6000 cases. ok on v4300; ok on trunk ./dbcook/tests$ make abc ARGS=doC inhs=c will run concrete inh, ~6000 cases... as i see 24% fail at v4300. IMO most of these are the below adressing-related ./dbcook/tests$ make abc ARGS=doC will run everything, ~14000 cases, ~1/2 hour things i remember right now (long time havent looked into that) - for proper addresing, primary key has to be somehow id+type; otherwise there is A with id=1 and also B with id=1 and C and... so cannot singly-reference an object. - all relations and some others (e.g. post_update in my case) has to be manualy inherited (=copied) - since day 1 i tried it. at certain time there were more issues around it. - *-to-many relations are terra-incognita, as they combine polymorphism with addressing... - once A,B,C works, try A,B,C,D in a case or two, all levels should have instances (A too!). only that covers it all (base + 2 levels + leaf, thats two overlapping 3-levels. uncovers SA logic at different angles) btw, if Mike is about delving into all this now, i think i have some time to look around it, at least move onto with_polymorphic. ciao svil On Monday 28 April 2008 19:07:51 Gaetan de Menten wrote: Hi there, I've been playing with concrete inheritance a bit these days (trying to implement it into Elixir). I've run into several problems, which might be known limitations, but I'd like to know for sure or be shown what I've done wrong... The two problems I get involve a chain of classes inheriting from one another: class C inherits from class B which inherits from class A. The first problem is that I can get a polymorphic load starting from class B. I'd like it to return instances of class C, along with the instances from class B. Querying class A works as expected though (return instances of A, B and C). See multi_level_concrete.py for what I tried. (It's a hacked/standalone version of the unit tests found in SA itself). FWIW, I run them with nosetest. The second (probably related) problem is that I can't get relationships to work polymorphically. I'd like to have a relationship to the B class. Since I've read in the doc that the relation is not inherited automatically, I tried duplicating manually, but then it doesn't work polymorphically... Anyway, see concrete_with_relations.py for my experimentations. Thanks in advance for any pointer on this, --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Apr 29, 2008, at 2:32 PM, [EMAIL PROTECTED] wrote: btw, if Mike is about delving into all this now, i think i have some time to look around it, at least move onto with_polymorphic. if you're going to deal with future functionality, go work with the user_defined_state branch for now, which will soon be merged to trunk as 0.5. The internals of with_polymorphic are again highly modified there. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Concrete inheritance woes
On Apr 28, 2008, at 12:07 PM, Gaetan de Menten wrote:
pjoin = polymorphic_union({
'manager':managers_table,
'engineer':engineers_table,
'hacker':hackers_table
}, 'type', 'pjoin')
mapper(Company, companies, properties={
'engineers':relation(Engineer, lazy=False,
enable_typechecks=False)
})
employee_mapper = mapper(Employee, pjoin,
polymorphic_on=pjoin.c.type)
manager_mapper = mapper(Manager, managers_table,
inherits=employee_mapper, concrete=True,
polymorphic_identity='manager')
engineer_mapper = mapper(Engineer, engineers_table,
inherits=employee_mapper, concrete=True,
polymorphic_identity='engineer',
properties={'company': relation(Company)})
hacker_mapper = mapper(Hacker, hackers_table,
inherits=engineer_mapper,
concrete=True,
polymorphic_identity='hacker',
properties={'company': relation(Company)})
OK...mapping Employee to pjoin is fine since its a virtual mapper.
For engineer_mapper, it needs a selectable from which it can also load
Hacker objects...this is the pjoin2 polymorphic_union you've created
in a later test. *but*, the engineer_mapper doesn't get mapped to it,
it should use it as its with_polymorphic argument (which used to be
handled by select_table):
pjoin = polymorphic_union(...)
pjoin2 = polymorphic_union(...)
employee_mapper = mapper(Employee, pjoin, polymorphic_on=pjoin.c.type)
manager_mapper = mapper(Manager, managers_table,
inherits=employee_mapper, concrete=True, polymorphic_identity='manager')
engineer_mapper = mapper(Engineer, engineers_table,
with_polymorphic=('*', pjoin2),
polymorphic_on=pjoin2.c.type,
inherits=employee_mapper, concrete=True,
polymorphic_identity='engineer')
hacker_mapper = mapper(Hacker, hackers_table, inherits=engineer_mapper,
concrete=True, polymorphic_identity='hacker')
this should in theory also fix the engineers relation on Company.
But as I've said many times (to svil, at least) concrete inheritance
is something i havent gotten into much as of yet, largely due to the
many inherent issues with it as well as its being a generally
unpopular pattern, so there may still be issues with this setup (but
let me know, since thats how it should work).
In any case the unit tests which you were working from (im guessing
test/orm/inheritance/concrete.py) should be patched to include this
test (i.e. including Hacker, the polymorphic load, as well as the
relation). Assuming it works we should also make sure the 0.5 branch
(which isnt called that yet) can handle it too.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
