I would agree except that fixture_id is not a join field. Its just a product of a legacy database that hasn't had all columns renamed to something sensible.
Here's another fun example: what do you think plane_747 means? I'd have guess a bool for type of plane. It actually means how long is the part. So yeah, ignore col names from my real life examples :-) I'm renaming the cols when I get to them though (and changing structures too) so it should get better. On Jul 10, 2009 8:16 AM, "Ryan Cone" <[email protected]> wrote: On Jul 9, 2009, at 9:21 PM, fREW Schmidt wrote: > > Anyway, I'm reading up on what another poster s... Both sides of this allow/disallow NULL issue are well represented online. I find that we generally pick one camp to fall into and rationalize our choices accordingly. For what it's worth, here is my rationalization...When using any ORM, I strive to create data objects that closely resemble my programmed ones. When I find myself "needing" a NULL, it often means I have not really defined my class properly. >From your original example you defined QCParts as having Fixtures. If a QCPart can exist without a Fixture, then the Fixture does not belong in the QCPart class. And you might need q_c_part_id in Fixtures or a Fixtures_QCParts table depending on the reverse relationship. If a QCPart cannot exist without a Fixture, then it seems that it should not be allowed to be unknown but may be allowed to be undefined-because per Darren Duncan's suggestion. -Ryan _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/lis...
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
