If you attempt to update a column that does not allow NULL to NULL, MySQL will set the column’s value to the default value for that column’s data type.  This is true only when you are not running MySQL strict mode.  Here’s an example to illustrate.

mysql> create table null_test (id int not null unique(id), name varchar(25)
null default null);
Query OK, 0 rows affected (0.01 sec)

mysql> show create table null_test;
+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table     | Create Table                                                                                                                                           |
+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
| null_test | CREATE TABLE `null_test` (
  `id` int(11) NOT NULL,
  `name` varchar(25) default NULL,
  UNIQUE KEY `id` (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
+-----------+--------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into null_test (id, name) values (1, 'Jane');
Query OK, 1 row affected (0.00 sec)

mysql> update null_test set id = null;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> select * from null_test where name = 'Jane';
+----+------+
| id | name |
+----+------+
|  0 | Jane |
+----+------+
1 row in set (0.00 sec)

More information about this bug can be found in the bug report submitted Janurary 4, 2008.

Unfortunately, MySQL does not support check constraints out of the box.  This makes the task of enforcing business logic in the database layer difficult, but not impossible.  I recently found this approach to implementing check constraints in MySQL.  It’s not as pretty and clean as I’d like, but, it’s the best approach that I’ve found so far.

Now. why would you want to encode business logic in the database?  Can’t you make due with your ActiveRecord::Validations?

Well, have you ever updated the database directly?  Have you ever called update_attribute on an object?  How about save_with_validation(false)?   Yeah, I thought so.  Read more about why you should treat your database as a fortress in Dan Chak’s recently released book, Enterprise Rails (review coming soon). ]]> http://www.jasonfox.com/2009/02/check-constraints-and-mysql/feed/ 0 http://www.jasonfox.com/2009/02/rewriting-sub-selects-as-joins/ http://www.jasonfox.com/2009/02/rewriting-sub-selects-as-joins/#comments Mon, 02 Feb 2009 23:07:14 +0000 admin http://www.jasonfox.com/?p=68 Your RDBMS will usually rewrite your sub-selects behind the scenes as joins.  However, there are times where you’ll want to do this yourself.  For example, past versions of MySQL did not play well with sub-selects.  Here are a couple examples of how to rewrite sub-selects as joins.

select *
from   table_a
where  id not in (select a_id from table_b);
-- can be rewritten as...
select *
from   table_a
left   outer join table_b on table_a.id = table_b.a_id
where  table_b.a_id is null;

select *
from   table_a
where  id in (select a_id from table_b);
-- can be rewritten as...
select *
from   table_a
left outer join table_b on table_a.id = table_b.a_id
where  table_b.a_id is not null;