>From the MySQL docs: Deviation from SQL standards: Like MySQL in general, in an SQL statement that inserts, deletes, or updates many rows, InnoDB checks UNIQUE and FOREIGN KEY constraints row-by-row. According to the SQL standard, the default behavior should be deferred checking. That is, constraints are only checked after the entire SQL statement has been processed. Until InnoDB implements deferred constraint checking, some things will be impossible, such as deleting a record that refers to itself via a foreign key.
As I read it, there is not a way to force InnoDB to check constraints at commit. And once there is it will be quite some time before the mass of MySQL instances support it. On Feb 27, 9:16 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > Hi all, > > Adrian has finally had a chance to look at, and approve the acceptance > of, the test fixtures patch. I sat down tonight to check in the patch, > did a last little check, and hit a snag - the trunk model tests break > under MySQL. Personally, I'm a Postgres jockey, so I need some > guidance from the MySQL-using community. > > The problem seems to have been introduced in [4610], and highlights in > MySQL the same problem that [4610] fixed in Postgres - when using the > InnoDB backend, foreign key constraints are checked per command, not > per-transaction, and as a result, saving forward references causes the > serializer model test to fail. If you have your MySQL setup to use > MyISAM (the default backend), you won't see the problem, because > MyISAM doesn't enforce constraints. > > This also ties in with #2720, which identified the fact that many > foreign key constraints aren't being created correctly under MySQL. > > Postgres has similar behaviour to InnoDB by default, but [4610] > modified the table declarations to disable constraint checking until > the end of a transaction using DEFFERABLE INITIALLY DEFERRED. However, > apparently MySQL doesn't implement this feature or an equivalent. > > One way around the problem would be to use SET FOREIGN_KEY_CHECKS at > the start and end of each transactions - but if I'm reading the docs > right, this wouldn't validate any keys modified while the checks were > disabled. > > Or, is there another approach that I am not aware of? > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
