[Phpmyadmin-devel] Grid editing

[Aris Feryanto]

On 5 Agu 2011, at 10:04, Aris Feryanto <aris_feryanto at yahoo.com> wrote:

>> From: Marc Delisle <marc at infomarc.info>
> 
>> Aris Feryanto a écrit :
>>>> From: Marc Delisle <marc at 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?

> 
>> 
>>> 
>>>> 5. 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