The 'has-a' allows you to implement the accessor without having to use the 'might-have'.

Specifically the docs say that the 'might-have' is used to establish a relationship where the key to the related table does not appear in the parent. But in your case it already does. I am short on time today so I can't give you a coded example, but I would suggest this - Data::Dumper is your friend.

Remove the 'might-have' - leave the 'has-a' - retrieve the data from the parent object and dump it. Now you can see the relationship, in place of the author id field in the parent you will see that the author object is now visible and is directly able to be accessed. Of course $article->author will return a blessed reference, but $author->article->id will give you the author id, and so on.

Here is the docs on the subject:

might_have

  Music::CD->might_have(method_name => Class => (@fields_to_import));

  Music::CD->might_have(liner_notes => LinerNotes => qw/notes/);

  my $liner_notes_object = $cd->liner_notes;
  my $notes = $cd->notes; # equivalent to $cd->liner_notes->notes;

might_have() is similar to has_many() for relationships that can have 
+at most one associated objects. For example, if you have a CD databas
+e to which you want to add liner notes information, you might not wan
+t to add a 'liner_notes' column to your main CD table even though the
+re is no multiplicity of relationship involved (each CD has at most o
+ne 'liner notes' field). So, you create another table with the same p
+rimary key as this one, with which you can cross-reference.

But you don't want to have to keep writing methods to turn the the 'li
+st' of liner_notes objects you'd get back from has_many into the sing
+le object you'd need. So, might_have() does this work for you. It cre
+ates an accessor to fetch the single object back if it exists, and it
+ also allows you import any of its methods into your namespace. So, i
+n the example above, the LinerNotes class can be mostly invisible - y
+ou can just call $cd->notes and it will call the notes method on the 
+correct LinerNotes object transparently for you.
[download]

I would not be surprised if Class::DBI chokes on having two relationships referring to the related data.

jdtoronto

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.