[Dbix-class] Re: '' != NULL for great sadness

[fREW Schmidt]

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" <metrext at gmail.com> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20090710/c5c=
daab0/attachment.htm