On 10/6/05, Uwe Voelker <[EMAIL PROTECTED]> wrote:
> Just for me to make it clear: If I run the same query first with
> require_objects and then with with_objects the number of (primary)
> objects returned by require_objects is always smaller or equal to
> with_objects? Because require_objects skips those Products who have no
> Price whereas with_objects returns all Products even with empty Price.
> (Products and Price as in the example from pod where 1 Product has N
> Prices.)
Yes.
> >>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?
>
> I'm not quite sure:
> 1. Is there a reason where we would need DISTINCT? (Performance when
> lots of duplicates)
Using DISTINCT will eliminate the duplicate rows in the database.
Leaving it out will make the Perl code do the duplicate elimination.
Sometimes the database will be faster, and sometimes Perl will be.
> So the question remains: Do we need both parameters?
> You could split it: "fetch_only" is an arrayref of tables, "distinct" is
> only a boolean.
Using DISTINCT without limiting the columns returned is expensive and
confers no benefits (all rows will be distinct anyway when considering
every single column), so I'd rather have the distinct param force you
to do both.
> Given the example with Price.region = 'DE': When I want to get a list of
> all regions I have to do "SELECT DISTINCT region FROM Price" - is there
> a way to do this in RDBO? It's not an object what is returned.
Since it's not an object returned, you either have to make it an
object by making a view based on "SELECT DISTINCT region FROM Price"
and then make an RDBO class to front that, or (my preferred solution)
you add can a custom method to your manager class. Example:
---
package Price::Manager;
...
sub get_all_regions
{
my($class, %args) = @_;
my @regions;
eval
{
my $db = $args{'db'} || Price->init_db;
my $dbh = $db->dbh;
my $sth = $dbh->prepare('SELECT DISTINCT region FROM ' .
Price->meta->fq_table_sql);
$sth->execute;
my $region;
$sth->bind_columns(\$region);
while($sth->fetch) { push(@regions, $region) }
};
if($@)
{
$class->error("get_all_regions() - $@");
$class->handle_error($class);
return;
}
return wantarray ? @regions [EMAIL PROTECTED];
}
---
But in reality, values like 'DE' are likely primary or unique keys
into a "regions" table that contains the expanded names of the
regions, etc. In this case, you can just use standard RDBO APIs to
get all the regions from your Region::Manager class.
-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
