MVC heresy
MVC
might not be the best possible architecture for web services? I buy
it - every good explanation I've heard of MVC included a GUI widget as
the Controller, which hardly has an analogue in the world of HTTP and
markup. It's also telling that the Smalltalk community from which MVC
originates has moved onto another approach.
[/code]
More MySQL 'features'
Last week I wrote about MySQL's approach to truncation on inserts. Little did I suspect that I would run into another, possibly more aggravating MySQL 'feature' not once, but twice over the next few days. That problem is its disinterest in case differences, even when the equals operator is in play. Example:
[/code]
Fri, 13 Aug 2004
Last week I wrote about MySQL's approach to truncation on inserts. Little did I suspect that I would run into another, possibly more aggravating MySQL 'feature' not once, but twice over the next few days. That problem is its disinterest in case differences, even when the equals operator is in play. Example:
mysql> desc testtext; +-------+------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------+------+-----+---------+-------+ | foo | text | YES | | NULL | | +-------+------+------+-----+---------+-------+ mysql> select * from testtext where foo = 'abc'; +------+ | foo | +------+ | Abc | +------+Catch that? I asked for rows where foo is 'abc', and got a row where it's actually 'Abc'. This 'feature' has a workaround, if your column is of type char or varchar: you can add the BINARY keyword to the column's declaration, and MySQL will stop ignoring the case. However, the data that I am working with does not always fit into the 255 character maximum supported by varchars, so I have been using, as in the example, the type 'text'. There is no BINARY keyword for text columns. However, it seems that all that separates 'text' from 'blob' columns is that the former ignore the case of their contents, and the latter do not:
mysql> desc test; +-------+------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------+------+-----+---------+-------+ | foo | blob | YES | | NULL | | +-------+------+------+-----+---------+-------+ mysql> select * from test where foo = 'abc'; Empty set (0.00 sec) mysql> select * from test where foo = 'Abc'; +------+ | foo | +------+ | Abc | +------+These 'features' and more are detailed at the excellent page MySQL Gotchas, the study of which is well-advised for all MySQL users.
[/code]
MySQL does things its own way
Here's how I'd expect an RDBMS to behave when I try to insert data that doesn't fit into the table spec. In this case, we have a postgreSQL table with field 'z' defined as varchar(2):
[/code]
Here's how I'd expect an RDBMS to behave when I try to insert data that doesn't fit into the table spec. In this case, we have a postgreSQL table with field 'z' defined as varchar(2):
test=# insert into foo (z) values ('toolong');
ERROR: value too long for type character varying(2)
But MySQL's philosophy is a little different. Here we try to insert a
string of 14 characters into a field defined as varchar(10):
mysql> insert into venue (zip,phone) values ('abcdefghijklmn','foo');
Query OK, 1 row affected (0.00 sec)
mysql> select zip, phone from venue where phone='foo';
+------------+-------+
| zip | phone |
+------------+-------+
| abcdefghij | foo |
+------------+-------+
1 row in set (0.08 sec)
This failure to raise an error is the same behavior you get when using
the various APIs to access MySQL, which means that your code can easily
get into a state where it thinks it's saved one string, but has actually
saved only the first x characters of that string. Madcaps ensue.
[/code]
slag code: