[Nottingham] SQLite and 'locking'

[Ovid]

--- Duncan John Fyfe <djf at star.le.ac.uk> wrote:

> But surely Martin's solution is wrong because it depends on a meaning
> being ascribed to NULL.  NULL can arise from conditions other than
> those
> anticipated and when it does you will be unable to distinguish 'not
> booked' from 'another condition you did not anticipate'.

Agreed, sort of.  The problem, as you point out, is that the meaning of
NULL is unknown.  For any given column, it might mean unknown,
inapplicable, unavailable, or something else entirely.  Given the
ambiguity and the well-known bugs that NULLs introduce, I would
strongly recommend avoiding them and in this case it makes sense, but
it's fair to argue that sometimes allowing this admittedly dodgy
construct is better than the alternatives.  See
http://web.onetel.com/~hughdarwen/TheThirdManifesto/Missing-info-without-nulls.pdf
 (http://tinyurl.com/267mob) for an extreme example of using 6th normal
form to eliminate NULLs.  However, it's fair to point out that the
design the author comes up with does eliminate ambiguity.
 
> PS.  perl -le 'print "yes" if (undef) < 4'
> 
> compare with 
> 	perl -le 'print "yes" if (6) < 4'
> 	perl -le 'print "yes" if ("a") < 4'
> 
> I think this is because "(undef)" is being parsed as a list with a
> single element (which happens to be undefined) while "(6)" is a
> numerical expression in parenthesis which is evaluated first.

Then we'll do it without the list:

  $ perl -le 'print "yes" if 4 > undef'
  yes

"4 > undef" is true in Perl, but in the real world it's ambiguous. 
That's another annoying source of bugs in Perl :(

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/