#2411 (ok 2.11) Cause of data manipulation issues

[crisp]

I ran into some data manipulation issues simular as to the ones mentioned at http://sourceforge.net/forum/forum.php?thread_id=1712782&forum_id=72909

I did some investigation and found that indeed this is an issue with POST-data not getting thru ok, but it's not solely a PHP issue.

The problem is more that the name-attributes of the form-fields are overly verbose since it contains an unserialized representation of the unique key of the field, for instance:

<input type="text" name="fields[multi_edit][`documents`.`id` = 1 AND `documents`.`page` = 1][id]">

Now this example won't cause any problems, but imagine what happens when you want to edit a record of a table that doesn't have a primary or unique key defined. In that case the unique key will be made out of all fields in the record and it's contents! That can lead to name-attributes of several kilobytes or possibly even megabytes long depending on the data in the record. You are easily hitting restrictions there. A better approach to prevent this verbosity, and since you already are defining the key in a seperate hidden field, would be to use some other unique identifier to group these fields, for instance:

<input type="hidden" name="primary_key[1]" value="`documents`.`id` = 1 AND `documents`.`page` = 1" />
<input type="text" name="fields[multi_edit][1][id]" />

where [1] is a simple counter that can be increased for each record

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

Thanks for your suggestion. I implemented it, see
http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin?view=rev&revision=10392

Please have a look (this is for trunk). I still have to find a problem: updating the value of an ENUM does not work with this new logic. If you have an idea... :)

[Marc Delisle]

Logged In: YES
user_id=210714
Originator: NO

Last part of the fix (for ENUM) merged in trunk.