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