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

Reply via email to