On 5 Agu 2011, at 10:04, Aris Feryanto aris_feryanto@yahoo.com wrote:
From: Marc Delisle marc@infomarc.info
Aris Feryanto a écrit :
From: Marc Delisle marc@infomarc.info
Le 2011-07-31 13:15, Aris Feryanto a écrit :
>> 3. I hope that we'll get the OK from other
developers to
remove
>> the row inline edit feature, because with the current
code,
>> >> 3.1 we have two features to do almost the same thing
3.2
>> currently, clicking on inline edit then on a cell
activates the
>> grid editing! > I hope so. Any objections?
Still waiting for input from other developers...
It seems there is no objection about this. Instead, positive feedback from
other phpMyAdmin developers.
Yes. Can you remove the row inline edit feature from your tree?
Sure. I will work on this.
Removed in my git.
>> 4. With this feature, we have the same problems as
with inline
>> edit, such as: >> >> 4.2 (major) For tables with a unique key, if this key
is
>> edited, the Edit, Copy and Delete links no longer
contain a
>> valid where_clause parameter and the multi-rows
actions at the
>> bottom (with selected) no longer work. >> >> 4.3 (major) For tables without a unique key, if any
column is
>> edited, the Edit, Copy and Delete links no longer
contain a
>> valid where_clause parameter and the multi-rows
actions at the
>> bottom (with selected) no longer work. > > Two problems above were fixed. It's a good progress but the fix is not complete.
About remark 4.2, the Delete link still refers to the old
unique
key.
It's weird, since this works in my test. Could you please
check this
again?
The real problem is that the confirmation message shown before deletion still contains the old key. Deletion itself works but I had stopped to test after seeing the wrong confirmation message.
Fixed
Confirmed.
About remark 4.3, the Edit link still points to the old data
and
fails, in the case of a table lacking a unique key.
Same as the response for 4.2, this works on my test. Could you
check
this again?
I confirm the problem, on a copy of the sakila.actor table where I have removed all indexes. I think it's because the last_update column (a timestamp) was updated via grid-editing but the URL still contains the previous value.
Fixed.
Problem 4.3 exists in your current tree. Tested with the Edit link on the sakila.actor table by changing the actor_id.
After some searching, problem 4.3 seems cannot be fixed, since any fields in where_clause can be modified when we execute an UPDATE statement (e.g., by Triggers, field with option "ON UPDATE CURRENT_TIMESTAMP").
IMO, the choices to solve this are: - to alert user when grid editing a nonunique row (telling that some features related to the edited table may not work after editing), or - disable the grid editing feature at all for nonunique rows
What would be the best choice?
- Just found out another problem, when the configuration AjaxEnable is
set to false.
Trying your version with latest commit 0d197603085c43cac543351795b3df6de4167b96 with Firefox 5 on
sakila.actor,
I cannot change the actor_id then click "Save edited data".
Look what
is generated:
UPDATE `sakila`.`actor` SET = '4002' WHERE `actor2`.`actor_id`
=2
Regarding the AjaxEnable setting, should the grid editing works when
AjaxEnable is set to off?
No.
I will work on this.
Fixed.
-- Aris Feryanto