Re: [RDBO] New find method type for one-to-many relationships
On Tue, 30 Jan 2007, [ISO-8859-1] Ask Bj?rn Hansen wrote:
(although I sometimes get tripped up by forgetting by how -new-load
needs unique keys).
Me too. Does new-load to be restricted to unique keys? Couldn't there
be a way to provide a query and call the manager under the hood to
find, say, the first matching record?
I'm using something like
###
sub db_find_or_create {
###
my($self, $class, $query) = @_;
my $cmgr = Rose::DB::Object::ConventionManager-new();
$method = get_ . $cmgr-class_to_table_plural($class);
my $files = (__PACKAGE__ . ::${class}::Manager)-$method(
query = $query
);
if($files-[0]) {
if(wantarray) {
return($files-[0], 0);
} else {
return $files-[0];
}
}
my $rec = (__PACKAGE__ . ::$class)-new(@$query);
if(wantarray) {
return($rec, 1);
} else {
return $rec;
}
}
which I'm calling like
my($obj, $was_created) = $self-db_find_or_create(
Someclass, [field = value]);
Is there a smarter way?
-- Mike
Mike Schilli
[EMAIL PROTECTED]
sub fetch {
my $self = shift;
my $obj = $self-object_class-new(@_);
$obj-load(speculative = 1) ? $obj : undef;
}
sub fetch_or_create {
my $self = shift;
my $obj = $self-object_class-new(@_);
$obj-load(speculative = 1);
$obj;
}
sub create {
shift-object_class-new(@_);
}
# Same as above (hashref as first arg is taken as query)
@low_prices = $p-find_prices({ price = { lt = 10 } });
This should make it easily call-able from Template Toolkit, too (for
better or worse).
- ask
--
http://develooper.com/ - http://askask.com/
-
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.phpp=sourceforgeCID=DEVDEV
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On Thu, 1 Feb 2007, John Siracusa wrote:
I question the wisdom of not supplying a sort_by paramater, however.
You're right, in the general case, sort_by is essential, but often
times, the application knows that there's either exactly one matching
record in the database or none.
It's something that I'm running into quite frequently:
I want to find out whether a matching record exists or not, and
load it if so. I guess it comes from using Class::DBI previously,
which allowed calls like
my $cd = Music::CD-find_or_create({ artist = 'U2', title = 'Boy' });
Just speculating: Could this be added to the new find() method?
And thanks for suggesting the get_objects() method, that was helpful.
-- Mike
Mike Schilli
[EMAIL PROTECTED]
On 2/1/07 1:14 PM, Mike Schilli wrote
On Tue, 30 Jan 2007, [ISO-8859-1] Ask Bj?rn Hansen wrote:
(although I sometimes get tripped up by forgetting by how -new-load
needs unique keys).
Me too. Does new-load to be restricted to unique keys?
Yes, because each object is linked to a single, uniquely identified row.
Couldn't there be a way to provide a query and call the manager under the
hood
to find, say, the first matching record?
Sure, but that's something very different than load() since the first
matching record depends on the sort order (if specified) or vagaries of the
database (if not). As you've shown, it's not a hard method to write.
You've made it a bit more difficult than you have to, however :)
The MyWhatever::Manager class methods are really just thin wrappers around
the generic Rose::DB::Object::Manager methods, with the object class fixed.
IOW, this:
$objects = MyWhatever::Manager-get_whatevers(...);
is equivalent to this:
$objects =
Rose::DB::Object::Manager-get_objects(object_class = 'MyWhatever',
...);
So you don't need to muck around with the convention manager or anything
like that. Here's a cleaned up version of your method (untested, but it
should be right...famous last words :)
sub db_find_or_create
{
my($self, $class, $query) = @_;
my $object_class = __PACKAGE__ . '::' . $class;
my $objects =
Rose::DB::Object::Manager-get_objects(
object_class = $object_class,
query= $query);
if(@$objects)
{
return wantarray ? ($objects-[0], 0) : undef;
}
my $object = $object_class-new(@$query);
return wantarray ? ($object, 1) : $object;
}
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On 30 Jan 2007, [EMAIL PROTECTED] wrote: In SVN, I've just added a new method type to one-to-many relationships (no docs yet). Right now, I'm calling it find. It's for fetching related objects using ad-hoc queries instead of being constrained to the mapping defined in the relationship metadata itself. It has no ability to set related objects; it just returns them. ... So, does this method type seem useful? If so, what do you think of the method type name (find) and the default method name format (find_relationship-name)? Finally, should this method type be created by default for all one-to-many relationships, or should it have to be manually requested in the relationship setup? It's exactly right. It should be created by default for all relationships. It will save me, at least, many lines of code. I would also ask for a load_speculative() method, which simply calls load with (speculative=1). I know about default_load_speculative, this is a local override. Yes, it pollutes the namespace--I think it's worthwhile. Ted - 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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
[RDBO] New find method type for one-to-many relationships
In SVN, I've just added a new method type to one-to-many relationships
(no docs yet). Right now, I'm calling it find. It's for fetching
related objects using ad-hoc queries instead of being constrained to
the mapping defined in the relationship metadata itself. It has no
ability to set related objects; it just returns them. Here's an
example using the Product/Price classes from the tutorial.
$p = Product-new(id = 123)-load;
## Example use of the default get_set_on_save method
## for the prices one-to-many relationship
@prices = $p-prices; # get
... # modify @prices in some way
$p-prices(@prices); # set...
$p-save; # ...on save (db modified here)
## Example use of the new find method for the prices
## one-to-many relationship
@high_prices = $p-find_prices(query = [ price = { gt = 99 } ],
sort_by = 'region',
...any other manager args here...);
@low_prices = $p-find_prices(query = [ price = { lt = 10 } ]);
# Same as above (arrayref as first arg is taken as query)
@low_prices = $p-find_prices([ price = { lt = 10 } ]);
# Same as above (hashref as first arg is taken as query)
@low_prices = $p-find_prices({ price = { lt = 10 } });
Every call to find_prices() goes back to the database to get new rows.
Those rows are returned, not saved in the parent object ($p) at all.
During each query, the mapping constraints defined in the relationship
metadata that connect the parent object to its related objects are
implicit, though they may be modified by conflicting, explicit
arguments in the call.
So, does this method type seem useful? If so, what do you think of
the method type name (find) and the default method name format
(find_relationship-name)? Finally, should this method type be
created by default for all one-to-many relationships, or should it
have to be manually requested in the relationship setup?
-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.phpp=sourceforgeCID=DEVDEV
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On 1/31/07, John Siracusa [EMAIL PROTECTED] wrote: So, does this method type seem useful? If so, what do you think of the method type name (find) and the default method name format (find_relationship-name)? Yes, this is very useful. I do this type of query all the time, and it is one of the very few things that I missed from my Class::DBI days. As for the name, 'find' is clear and concise, so it works for me. Finally, should this method type be created by default for all one-to-many relationships, or should it have to be manually requested in the relationship setup? For me it is useful enough that it is worth including by default. But as long as it is configurable in the convention manager or base class it's OK either way (I actually haven't had to use the convention manager yet, since the default conventions used in RDBO match up closely with the way I like to do things). Cheers, Cees - 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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On 1/30/07 6:18 PM, Cees Hek wrote: Finally, should this method type be created by default for all one-to-many relationships, or should it have to be manually requested in the relationship setup? For me it is useful enough that it is worth including by default. But as long as it is configurable in the convention manager or base class it's OK either way This sort of thing would be configured in the Metadata class, not the CM, since it affects the number and type of methods created for each relationship in a class, not what those method, relationships, and classes are named, or how they're derived from the database tables. -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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
So, does this method type seem useful? If so, what do you think of the method type name (find) and the default method name format (find_relationship-name)? Ruby uses find. If it's good enough for ruby, it's good enough for me :-) I agree that it seems obvious the results won't be cached. What happens when you call -find_prices with no args? regards, Danial -- When I was a kid I used to pray every night for a new bike. Then I realised that the Lord doesn't work that way so I stole one and asked him to forgive me. - 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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On 1/30/07 7:59 PM, Danial Pearce wrote: What happens when you call -find_prices with no args? It's essentially the same as calling a get_set_* method: all the related objects (as determined by the relationship metadata) are returned. But if that's really what you want, you'd just call $p-prices() instead. -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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On Jan 30, 2007, at 12:55, John Siracusa wrote:
I like it!
We have all sorts of utility methods in our model classes to fetch
child objects where just calling -children wasn't exact enough.
On a vaguely related note, in our manager class we have the following
three methods. In particular the first one is incredibly helpful
(although I sometimes get tripped up by forgetting by how -new-load
needs unique keys).
sub fetch {
my $self = shift;
my $obj = $self-object_class-new(@_);
$obj-load(speculative = 1) ? $obj : undef;
}
sub fetch_or_create {
my $self = shift;
my $obj = $self-object_class-new(@_);
$obj-load(speculative = 1);
$obj;
}
sub create {
shift-object_class-new(@_);
}
# Same as above (hashref as first arg is taken as query)
@low_prices = $p-find_prices({ price = { lt = 10 } });
This should make it easily call-able from Template Toolkit, too (for
better or worse).
- ask
--
http://develooper.com/ - http://askask.com/
-
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.phpp=sourceforgeCID=DEVDEV
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On 1/31/07, Ask Bjørn Hansen [EMAIL PROTECTED] wrote:
sub fetch {
my $self = shift;
my $obj = $self-object_class-new(@_);
$obj-load(speculative = 1) ? $obj : undef;
}
Amazing. We also use the exact same method. Well, almost. We golfed
that shift a bit ;-)
I wonder if this has a place in Rose itself?
--
When I was a kid I used to pray every night for a new bike. Then I
realised that the Lord doesn't work that way so I stole one and asked
him to forgive me.
-
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.phpp=sourceforgeCID=DEVDEV
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
On Jan 30, 2007, at 7:48 PM, John Siracusa wrote: Given that this method will always be called with arguments, and that those arguments can change per-call, how can there be any expectation that the results will be saved internally? How would such a feature even work? it wouldn't -- i can't imagine any circumstance in which it could. The whole point of the find method is to allow ad hoc queries. Think of it as a Manager call with the query parameters that link one object to another being implied, rather than explicitly visible in the args. i'm in 100% agreement. but the manager class is that 'special' place where all sorts of conditional stuff happens. it just seems counter-intuitive to everything else in the base rose class to me. If someone wants to keep the results of a find method call around for a while, they certainly have the means to do so by...keeping the results around for a while! :) # Keep @prices around until it's no longer needed @prices = $p-find_prices(...); If there exists a well-defined set of related objects that you want to be able to keep inside the parent object, just create a relationship with all the parameters that define this set, then use the usual get_set_on_save method. i have no qualms with that. i just think that the nature of this new function requires that the user be made painfully aware of this departure from the standard workings. 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 b- the function require a flag that the user know whats going on c- this be placed not in rose::db::object, but in some other class which extends rose::db::object ( rose::db::objectalt ) 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. - 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.phpp=sourceforgeCID=DEVDEV ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] New find method type for one-to-many relationships
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.phpp=sourceforgeCID=DEVDEV
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
