On 28 Sep 2009, at 5:51am, Darren Duncan wrote:
> Robustness comes in several ways. One is that with less code mass
> their tends
> to be fewer places to have bugs, all other things equal; when you make
> developers write more, they are more likely to make mistakes.
> Another piece of
> robustness is resilience under change. If you periodically change
> what detail
> columns a table has, and you want your queries to return all the
> detail columns
> in most situations, then any queries not mentioning the detail
> columns in an
> "except" will automatically work following the updates, same as a
> "select *"
> does; you don't have to go back and update every instance to just
> keep up.
Unfortunately, one thing this feature does is add another opportunity
for producing error messages. Consider a table with six columns: one
two three four five six. I want all but the last one. Normally I'd do
SELECT one,two,three,four,five FROM myTable
or
SELECT * FROM myTable
and just loop through the first five answers. But with this extension
I can now do
SELECT ALLBUT six FROM myTable
which is shorter, so fine. Over a few months I gradually realise that
I never use column six any more since I always calculate it from other
things. So I drop it from the table. Once I've done that, both forms
of the command I used originally
SELECT one,two,three,four,five FROM myTable
and
SELECT * FROM myTable
still work perfectly. But if I've used this new form
SELECT ALLBUT six FROM myTable
I now have to go through my code changing all those statements to
something else. So this new form is not more resilient under change.
It's more resilient under /some/ types of change but less resilient
under this type of change that's actually most likely to happen.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
