On 7/28/06 2:29 PM, Randal L. Schwartz wrote: > So I have $client who has abstract table B which is implemented as B1, B2, B3, > and B4, all inheriting B. There are no B rows. However, there's table A > which asks for a "B" as a foreign key reference.
If there are no B rows, how does that work in the db? I'v enever used Pg's table inheritance... > Now, how do I model this mess with Rose? I suspect that the code that takes a > "B" key and turns it into the row can ask the database which "real" table name > the row belongs, and do the right thing. (I've worked that out somewhere... > you can ask for the table oid for a row and do some magic in the system tables > to get the name of the table.) Yuck! > But how many other things would this break? If I tell Rose that following > A->B gives me a B, but it really gives a B1, does that violate any > assumptions? I think the second you try to fetch an A's associated B object, Rose will fail because it'll try to look up a row in the B table, not B1 or B2 or whatever. If you can give me a concrete (simplified) example schema, I can see if I can add the appropriate hooks to make it possible for a fk or relationship to point to a dynamically selected class, rather than just one static class. In all cases, there'll need to be RDBO classes for each table (virtual or otherwise) involved: A, B, B1, B2, B3, etc. > And if I come back the other way, getting all rows of the one-to-many in the > other direction, can I tell Rose that it doesn't need to call the code in > B1... it can just call it in B? Er, I'm not following that bit. > And can I tell Rose that B1 @ISA B, so I can define generic additional B-like > things for both the manager and row classes? For the object class, yeah. See the "Inheritance" section: http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object.pm#Inheritance You'll need to generate Manager classes for each B* class, however. Once I roll out the change mentioned earlier where the object_class parameter defaults to the return value of object_class(), then you'll be able to do this: package B::Manager; ... package B1::Manager; use base 'B::Manager'; sub object_class { 'B1' } package B2::Manager; use base 'B::Manager'; sub object_class { 'B2' } and so on. > And more importantly, has anyone *done* this already with Rose, so I don't > have to be the pioneer with the arrow in my head? :) Not me...I've tended to avoid Pg's table inheritance since it's oh-so non-portable and strange :) -John ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
