On 1/30/07 11:16 PM, Jonathan Vanasco wrote:
> the consensus is clearly otherwise, but let me expand my suggestions to:
>
> a- the name semantically notes that it doesn't alter the object
> like other rose functions
I think "find" expresses that pretty well already.
> b- the function require a flag that the user know whats going on
I think that's overkill. Anyone who knows about these method sat all will
have learned about them from the docs, which will explain how they work.
> c- this be placed not in rose::db::object, but in some other
> class which extends rose::db::object ( rose::db::objectalt )
It's just a method type for a relationship. There are already more of those
than are used by default, many of which act very differently than the
default get_set_on_save methods (e.g., add_now)
> i think my issue is that it functions so much like a manager call and
> not like a rose object , yet the point of it is to have the
> functionality of a manager call in the object itself.
Right, because it's cumbersome to look up and then express the "linking
conditions" of a relationship manually in a Manager call. A task like "get
all the prices for this product" is made easy by the default get_set_on_save
relationship method: @p = $p->prices. But an only slightly modified task
like "get all the prices for this product that are more than $5" becomes a
(relatively) giant Manager call with hard-coded linking conditions in the
query:
@high_prices =
Price::Manager->get_prices(query =>
[
product_id => $p->id,
price => { gt => 5 },
],
sort_by => 'price);
That's a big step down in easy of use and maintainability for what is only a
slight modification of a formerly simple task. And if the "prices"
relationship changes, linking back to product in a new way or with new
conditions, then you have to go through the code and find these hard-coded
Manager queries and change them too.
What's needed is an ability to arbitrarily filter the prices related to a
particular product on an ad hoc basis. That ability can't be added to the
get_set_on_save method because its incompatible with the way that method
works. Thus the need for a new, "fetch-only" method type, which I'm calling
"find" for lack of a better name.
@high_prices = $p->find_prices({ price => { gt => 5 }, });
Although that is equivalent to the Manager call above, it's much shorter and
it's more maintainable in the face of relationship changes. I think it's
also validly an object method because the implicit link of the results to
the parent object is an essential (and non-overridable) part of the Manager
query that's run behind the scenes.
-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
