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

    @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.


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
Rose-db-object mailing list

Reply via email to