Hello John,
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.
All that leaves is the "distinct" issue and the fact that you only
want to fetch certain columns.
The DISTINCT is to avoid double objects, if an product has two prices in
a region 'DE'
Well, you won't actual get any doubles in your return value, of
course, but yes, redundant data will be fetched behind the scenes.
Ok. But lets say I have lots of prices (and the rows are filled with
blobs) and so it would be significant.
But calm down, my currect application doesn't have such a setup :-)
To solve that, I'm thinking of adding something like this:
$p = Product::Manager->get_products(
distinct => [ 't1' ],
require_objects => [ 'prices' ],
query => [ 't2.region' => 'DE' ])
which would produce SQL like this:
SELECT DISTINCT t1.*
FROM products t1 LEFT JOIN prices t2 ON (t1.id = t2.product_id)
WHERE t2.region = 'DE'
Ah great. So with 'distinct' the behaviour of 'require_objects' or
'with_objects' is modified to not fetch the subobjects.
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)".
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?
I'm sure I missed something. Could you please explain a little bit more?
Thanks.
Possible values for the "distinct" param would be:
* True scalar value:
distinct => 1 # DISTINCT t1.*
* List of table names or aliases
distinct => [ 't1', 't3' ] # DISTINCT t1.*, t3.*
What do you think?
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.
Given that I can solve my problem now, this "distinct" issue has no
longer a "top priority" for me. But another question arises (see my
other mail).
Thanks,
bye, Uwe
-------------------------------------------------------
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