On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote: >> I don't recall why I had that constraint in there, but I'm pretty sure >> there was a good reason. I'll look into it. > > I just read your mail that you removed this constraint. But I'm curious: > Did you find what the reason was? I'm interested in it.
As far as I can remember, it the constraint was introduced because incorrect data used to be returned when multiple "... to many" require_objects args were passed. Since then, I've changed the order of the tables in the FROM clause for unrelated reasons, and that seemed to fix this problem too. > Btw. I have read again the RDBO::Manager doc and 'require_objects' > doesn't say "I fetch subobjects too" but 'with_objects' says explicitly > "I also fetch subobjects (if any)". The docs for require_objects say: "Only fetch rows from the primary table that have all of the associated sub-objects listed in OBJECTS" whereas the docs for with_objects say: "Also fetch sub-objects (if any) associated with rows in the primary table" I think that's pretty clear. > So now the only difference between 'require_objects' and 'with_objects' > is the inner/normal join for require_objects and an outer join for > with_objects. But if the foreign key column is NOT_NULL the also > with_objects does an inner join. So for these relations with_objects is > the same as require_objects? Yeah, but those are all implementation details, really. The distinction as far as the API is concerned is that, if you use require_objects, every object returned will have those sub-objects. If you use with_objects, some might and some might not. > I'm fine with that. I especially like the "shortcut" 'distinct => 1'. > But distinct => [...] has a double meaning: distinct and "fetch only > this tables/objects". But I think this is only a minor problem. Hm, well how about a fetch_only param that means the same thing as the proposed distinct param, but omits the keyword DISTINCT? -John ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
