|
Sunday 06 July 2008 10:17:05 pm
Actually - we only use InnoDB, but no constraints seem to be there out of the box.
No, because (a) eZ Publish started with MyISAM only for MySQL and (b) I think MyISAM is still supported.
Shouldn't transactions take care of the problem, though?
Transactions say nothing about the data entered. It's just a protection in case it goes wrong so you don't get half of the data in the db while the other half failed. As long as all database conditions are met (not null columns, datatypes, query syntax, ...) there is nothing to stop bad data from going in.
To illustrate the difference:
You create your own query to add a row in the ezcontentobject_tree table and you wrap it in a transaction. Unfortunately, you introduced a bug somewhere in the code resulting in multiplied parent node ids (which is a foreign key in that table). Two situations: node id A is double of its expected value, but still exists in the db; node id B does not exist at the moment.
The database with only transactions:
- A: The query will be executed and the row added
- B: The query will be executed and the row added
The database with transactions and foreign key constraints:
- A: The query will be executed and the row added
- B: The query will be executed and will fail, triggering a rollback due to the transaction. So you can see that contraints don't give full protection, but they do take out bogus entries where foreign keys would point to a big void. They also come into play when you're deleting stuff to make sure the database remains in a consistent state.
Hans
http://blog.hansmelis.be
|