[Dbix-class] Re: BUG? Unable to resolve relationship

[Adam Sjøgren]

On Tue, 15 Dec 2009 11:10:20 +0100, Peter wrote:

> Implementors usually suck at writing wholesome documentation. Could
> you be so kind to submit a patch against [1]. You will have both a
> better idea where to put the text so a user will find it, and also how
> to word such text so it makes sense to a novice.

I don't know about that, but I do know that your explanation here made
it much clearer to me what 'might_have' does.

(Had it been called 'might_have_one', then the name would have triggered
the same enlightenment on my part, but I was probably just being dense
thinking 'might_have_some'.)

Here is a patch against trunk (it might be out of style to have such a
clarifying note in the middle of the reference documentation, but as I
(re-)read the 'has_many' and 'might_have' sections, it would have helped
me grasp the difference):

Add a note to 'might_have' to clarify the difference from 'has_many'

---
 lib/DBIx/Class/Relationship.pm |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/lib/DBIx/Class/Relationship.pm b/lib/DBIx/Class/Relationship.pm
index 3351391..2727397 100644
--- a/lib/DBIx/Class/Relationship.pm
+++ b/lib/DBIx/Class/Relationship.pm
@@ -371,6 +371,10 @@ resolve the join, unless C<$their_fk_column> specifies the foreign key
 column in C<$related_class> or C<cond> specifies a reference to a join
 condition hash.
 
+This differs from C<has_many> in that a C<might_have> relationship
+returns undef or exactly one row, while has_many returns a resultset
+(which can match no, one, or more rows.)
+
 =over
 
 =item accessor_name
-- 
1.6.3.3


-- 
                                                          Adam Sjøgren
                                                    adsj at novozymes.com