Upd: описанный ниже эффект проявляется только в MySQL ниже 5.1.25 — спасибо pharod.
Случайно обнаружился интересный эффект, приводивший к багу в приложении:
Кажется, что запрос не завязан на конкретную схему таблицы и может быть выполнен и после изменения схемы. В действительности prepared statement закладывается на список колонок, который был на момент создания statement.
В реальной жизни проблема обнаружилась так: класс, отвечающий за общение с базой, кэширует prepared statements. Закэшированные statements поломались, когда потребовалось во время выполнения менять схему базы (не спрашивайте, зачем потребовалось: не всё в жизни делается так, как нам хочется). Будьте осторожнее!
Случайно обнаружился интересный эффект, приводивший к багу в приложении:
mysql> create table test(a int,b int);
Query OK, 0 rows affected (0.11 sec)
mysql> prepare ps from "select * from test";
Query OK, 0 rows affected (0.00 sec)
Statement prepared
mysql> alter table test drop column b;
Query OK, 0 rows affected (0.27 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> execute ps;
ERROR 1054 (42S22): Unknown column 'testdb.test.b' in 'field list'Кажется, что запрос не завязан на конкретную схему таблицы и может быть выполнен и после изменения схемы. В действительности prepared statement закладывается на список колонок, который был на момент создания statement.
В реальной жизни проблема обнаружилась так: класс, отвечающий за общение с базой, кэширует prepared statements. Закэшированные statements поломались, когда потребовалось во время выполнения менять схему базы (не спрашивайте, зачем потребовалось: не всё в жизни делается так, как нам хочется). Будьте осторожнее!
