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
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
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, almo
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
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/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->pri
> 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
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
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 s
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
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
On 1/30/07, Derek Watson <[EMAIL PROTECTED]> wrote:
> I am using RDBO in conjunction with Rose::HTML::Form for the first time, and
> wonder if there are any guides or examples out there showing some
> conventional integration techniques. Specifically, how best to use RHF's
> objects returned by ob
Hello,
I am using RDBO in conjunction with Rose::HTML::Form for the first time, and
wonder if there are any guides or examples out there showing some
conventional integration techniques. Specifically, how best to use RHF's
objects returned by object_from_form() style methods to update database
r
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" relat
14 matches
Mail list logo
