PMA version 3.2.0.1, MySQL server version: 5.0.51b-community-nt-log
CREATE TABLE foo (foo_uuid CHAR(36) PRIMARY KEY, foo_data INT);
Insert a row. Leave the foo_uuid column empty, but enter 123 in the foo_data column. PMA executes the following command:
INSERT INTO `test`.`foo` ( `foo_uuid` , `foo_data` ) VALUES ( UUID( ) , '123' );
Note that it has automatically assigned the foo_uuid column. Now, edit the row, changing 123 to 456. PMA executes the following SQL:
UPDATE `test`.`foo` SET `foo_uuid` = UUID( ) , `foo_data` = '456' WHERE `foo`.`foo_uuid` = '87a46e15-c545-102c-bd9f-d5b50e269472' LIMIT 1 ;
Note that it is *changing* the existing value of foo_uuid.
This is wrong. UUID values should be fixed, once they are created. Changing them breaks foreign-key relationships, etc.
Fixed in subversion, thanks for reporting.
Tested and works OK. Thanks for the quick fix.
While this bug has been fixed on July 2009, it's not fixed in PMA 3.2.3 released end of october. Would be great if the fix could be ported (and also if it was possible to know which svn revision is the fix, so I can apply it too).
This was originally committed to trunk in revision: 12675
http://phpmyadmin.svn.sourceforge.net/phpmyadmin/?rev=12675&view=rev
I just backported this to the QA_3_2 branch, so it should be in 3.2.4