Hello,
I'm curious about why object inflation isn't working with might_have or
has_one, but it does with belongs_to. Any ideas? Maybe I need another join
(adding this comment at the end)?
After solving it with a hack (use get_column and then model->find using that
id), I discovered that not using belongs_to would cause inflation to stop
working.
in CatMgrDB/Listing.pm:
__PACKAGE__->might_have( coupon => CatMgrDB::Coupon);
(works if changed to belongs_to, which works with the other relations)
in CatMgrDB/Coupon.pm:
__PACKAGE__->belongs_to( listing => 'CatMgrDB::Listing', 'listing', {join_type
=> 'left'});
in Controller/Admin.pm:
my $listing = $c->model('CatMgrDB::Listing')->find($listingid);
my $coupon = $listing->coupon; # this is undef for might_have but works for
belongs_to
I think my own troubles with this case and also the to me startling
autovivification a week ago are a documentation problem, which I'm willing to
contribute to fixing. I solved the autoviv. then by making relations all
belongs_to or has_many, and adding a dummy record id 0 for each table (instead
of allowing nulls) since I was worried about what my client might do to it
afterwards.
So the docs should explain autovivification as the system "doing the right
thing", which I suppose is a basic of ORMic programming, and also another basic
that relations are only unidirectional. The English language of the method
names was confusing because of similarities and also because one might think a
single belongs_to line would naturally create an accessor in the other object.
And my use of might_have in Listing was chosen as an inverse of the belongs_to
in Coupon. (Certainly a coupon does not own a listing in my scheme but perhaps
they should belong_to each other if they store each other's id?)
Personally I am most concerned about what may be considered "side effects",
such as autovivification, inflation failing, cascading updates or deletes being
enabled or not by default, etc. So that I have to test very carefully to see
exactly what behavior is being generated.
Anyway I am curious about why object lookup fails when I change from
belongs_to. Since I have a dummy object I suppose I could just make might_have
into belongs_to as well, but I didn't want to create a coupon by accident just
in case "doing the right thing" caused autovivification, and avoided it and any
business repercussions that might have.
Thanks and sorry for the lengthy post. Perhaps it is really 2 posts, the second
being on documentation. Please don't take it the wrong way, I think this is a
great project and it is very useful. But for someone not intimately familiar
with the design philosophy behind it there are gotchas, and maybe some added
docs would help in reducing traffic on this list. Just my 2 cents.
Sincerely,
Matt Rosin
____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/[email protected]/
