Re: [RDBO] New "find" method type for one-to-many relationships
On 2/1/07 3:21 PM, Mike Schilli wrote:
> 1) Two columns of a table form a combined unique key, but neither
>of them can be defined UNIQUE().
Then you'd just define a unique key using those two columns:
SQL: UNIQUE(col1, col2),
RDBO: unique_key => [ 'col1', 'col2' ],
> 2) You have a "unique key" that spans several tables:
>
> CREATE TABLE bars (
> id INTEGER AUTO_INCREMENT PRIMARY KEY NOT NULL,
> string VARCHAR(255),
> UNIQUE(string)
> )Type=InnoDB;
>
> CREATE TABLE foos (
> id INTEGER AUTO_INCREMENT PRIMARY KEY NOT NULL,
> bar_id INTEGER,
> UNIQUE(bar_id),
> FOREIGN KEY(bar_id) REFERENCES bars(id),
> INDEX(bar_id)
> )Type=InnoDB;
>
> my $foo = Rosetest::Foo->new(bar => { string => "moo!" });
> $foo->load(speculative => 1); # Error
> $foo->save();
Multi-table searches are pretty clearly the domain of the Manager, IMO.
> 3) The application isn't at liberty to change the db and must
>work with a crappy legacy schema.
Yeah, that's always annoying, but also hard to anticipate. Everyone's
legacy problems are different.
-John
-
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=lnk&kid=120709&bid=263057&dat=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:
> Maybe you should share that information with the database... :)
Ha :). I can think of 3 different scenarios:
1) Two columns of a table form a combined unique key, but neither
of them can be defined UNIQUE().
2) You have a "unique key" that spans several tables:
CREATE TABLE bars (
id INTEGER AUTO_INCREMENT PRIMARY KEY NOT NULL,
string VARCHAR(255),
UNIQUE(string)
)Type=InnoDB;
CREATE TABLE foos (
id INTEGER AUTO_INCREMENT PRIMARY KEY NOT NULL,
bar_id INTEGER,
UNIQUE(bar_id),
FOREIGN KEY(bar_id) REFERENCES bars(id),
INDEX(bar_id)
)Type=InnoDB;
my $foo = Rosetest::Foo->new(bar => { string => "moo!" });
$foo->load(speculative => 1); # Error
$foo->save();
3) The application isn't at liberty to change the db and must
work with a crappy legacy schema.
-- Mike
Mike Schilli
[EMAIL PROTECTED]
> > 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?
>
> It's something entirely different. The only thing in common is the word
> "find". There's already a load_or_save() Helper method, but with the word
> "load" in there, it of course needs a unique key. I think I'd have to see
> some more requests and usage examples before adding something like the
> db_find_or_create() method posted earlier. Right now, it seems very odd to
> me. What does everyone else think?
>
> -John
>
>
>
> -
> 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=lnk&kid=120709&bid=263057&dat=121642
> ___
> 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=lnk&kid=120709&bid=263057&dat=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 2/1/07 2:03 PM, Mike Schilli wrote:
> 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.
Maybe you should share that information with the database... :)
> 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?
It's something entirely different. The only thing in common is the word
"find". There's already a load_or_save() Helper method, but with the word
"load" in there, it of course needs a unique key. I think I'd have to see
some more requests and usage examples before adding something like the
db_find_or_create() method posted earlier. Right now, it seems very odd to
me. What does everyone else think?
-John
-
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=lnk&kid=120709&bid=263057&dat=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=lnk&kid=120709&bid=263057&dat=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 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;
}
I question the wisdom of not supplying a sort_by paramater, however.
-John
-
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=lnk&kid=120709&bid=263057&dat=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 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.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
>
-
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=lnk&kid=120709&bid=263057&dat=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_")? 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.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
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.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
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.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
Re: [RDBO] New "find" method type for one-to-many relationships
On 1/30/07 9:57 PM, Danial Pearce wrote:
> 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?
If anyone wants to create and submit a Rose::DB::Object::Manager::Helpers
module filled with such things, feel free! :)
(plus docs and tests, naturally ;)
-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
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.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
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.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
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.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
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_")?
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.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
Re: [RDBO] New "find" method type for one-to-many relationships
On 1/30/07 7:16 PM, Jonathan Vanasco wrote: >> 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. > > what about temp_find , return_only_find , or something else in the > name to reflect that the results aren't saved ? > > or maybe just require an argument like 'return_only => 1' or > something similar, > > my main concern is for people who are looking at other's code , or > haven't touched rose in a while , will know that nothing is saved by > this operation. 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? 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. 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. -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
Re: [RDBO] New "find" method type for one-to-many relationships
On Jan 30, 2007, at 3:55 PM, John Siracusa 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_")? 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?
nice work
but i'm a little uneasy with find , simply because:
> 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.
what about temp_find , return_only_find , or something else in the
name to reflect that the results aren't saved ?
or maybe just require an argument like 'return_only => 1' or
something similar,
my main concern is for people who are looking at other's code , or
haven't touched rose in a while , will know that nothing is saved by
this operation.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| SyndiClick.com
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
-
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
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.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
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_")?
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.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
