Hi, thanks for your comment. But,
1. I use NOT_NULL so my program has less opportunity to ever crash :) no really
I saw DBIxC crash in the past I'm pretty sure though cannot document now,
perhaps the calling a method on a nonexistent object error... I would prefer it
to say "0" than to crash. Perhaps other people have smarter ways to improve
robustness...
2. At any rate, I do not think it is doing the right thing, regardless. It is a
bug if you cannot test for whether the related object exists, and when an SQL
insert is generated on another table. In particular I think this is happening
mainly during interpretation of TT2's dot notation. I would expect
$mytransaction->customer->b_company not to create a Customer object in the db
too. Am I wrong in this? So should I either allow NULL in transaction.customer
or else use might_have? The might_have docs suggest cascading updates too...
Matt
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
