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,
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
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
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
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
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
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.
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
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
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
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
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
12 matches
Mail list logo
