in reply to Class::DBI and might_have problem

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.
I would not be surprised if Class::DBI chokes on having two relationships referring to the related data.

jdtoronto

Replies are listed 'Best First'.
Re^2: Class::DBI and might_have problem
by debiandude (Scribe) on Jun 07, 2006 at 19:36 UTC

    The reason I was thinking I wanted to use might_have because I like the idea of beging able to just write:

    $article->author

    If I instead use the has_a relationship I need to write:

    $article->authorId->author

    I guess I am still a little muddled on the diff between has_a and might_have. Since it seems that might_have provides a type of access that has_a does not. But they are not replacements for each other?