Thanks for the timely response. >> Table b has an FK to table a. Table b also has an FK to table c. These FK >> columns are all NOT NULL constrained. >> > > If that is the case, and if referential integrity is turned on for the > foreign key that links b to c, then you are telling RDBO that no row > in b can ever exist without a corresponding row in c. Thus, the > behavior you observe is valid: > > If I was using table b as the foundation of the query (i.e. MyApp::Model::B::Manager->get_objects()), then I would agree with you. But I'm not; I'm using table *a* as the foundation (i.e. MyApp::Model::A::Manager->get_objects()), which does not have an FK to table b -- it only has a one-to-many relationship to table b. Thus, by putting b and b.c in 'with_objects', I'm saying that I definitely want my 'a' records, and whatever 'b' and 'b.c' records there might be (excluding any additional limits I choose to put in the where clause).
Doesn't putting 'b' in the 'with_objects' set make 'b' records desired -- but, critically, optional -- for the query result? In which case, while the behaviors regarding foreign keys with full referential integrity enabled are appropriate in determining what 'b' records (and 'c' records) show up in the result, it should not influence whether an 'a' record can or cannot be returned? That's the point of my email; this relationship between b and c and its surrounding rules are preventing the 'a' records from showing up, when I've asked for 'b' records in a "give 'em if you've got 'em" fashion (as opposed to the "only give 'em if its got 'em" approach of 'require_objects'). Does that make more sense? >> Where I to use get_objects for table a, it would be reasonable to use a >> with_objects setting of: [ qw( b b.c ) ] >> >> However, this will fail to return any records for which table c cannot >> be found, despite the fact that table c is requested as a member of >> with_objects rather than require_objects. >> > > If you do not want this behavior (say, because you're using a database > that does not enforce referential integrity on its foreign keys, even > when the columns involved are NOT NULL), then turn off the > refferential_integrity attribute for the foreign key that links b to > c: > > http://search.cpan.org/dist/Rose-DB-Object/lib/Rose/DB/Object/Metadata/ForeignKey.pm#referential_integrity > Yes, I noted this in my initial email. :) Thanks again for your response. - Ethan -- Ethan Rowe End Point Corporation [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
