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
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 sev
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
>
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 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 sin
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, s
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
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
18 matches
Mail list logo
