#4805 (ok 4.4.1) inline edit broken when using functions in query
When issuing a "SELECT * FROM [table]", I can inline edit values. However, if the query is something like "SELECT *, SHA1([…]) FROM [table]", it breaks.
I tested with 4.3.11.1, 4.3.12 and 4.4.0 (demo server).
Reproduction:
CREATE TABLE IF NOT EXISTS inlinetest (
id int(11) NOT NULL,
msg varchar(63) NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
INSERT INTO inlinetest (id, msg) VALUES
(1, 'abc');
ALTER TABLE inlinetest
ADD PRIMARY KEY (id);
Steps:
Browse the table using "SELECT *, SHA1([msg]) FROM [inlinetest]". The first thing I notice is that usually, there is an "edit" and "delete" link to edit/delete a record. This is not shown. But still, inline edit is not disabled (maybe this is the actual bug?).
Double click on "msg". Inline edit the value to something else. Hit return.
The created SQL query contains an empty "WHERE" clause. Click on "edit" in the error message and you can edit the broken SQL query. Wait a few seconds and a new notification overlay pops up. And this one seems to contain a "browse" query response. - tested in 4.3.12-dev
In 4.4.0-beta1, a JavaScript error gets reported: "A fatal JavaScript error has occurred. Would you like to send an error report?"
Hello,
I am interested in fixing this. I think the issue is with Phpmyadmin allowing the user to inline edit computed columns or columns whose values have been computed using some functions.
I see two options:
(1) Disabling inline edit entirely for those result tables across all the columns which were generated from a query containing a function:
I think this was the original intent as Phpmyadmin doesn't show edit delete copy options for records in the result table if a function is present in the query.
(2) Disabling inline edit only on those columns which contain a computed value: This "may" take an awful lot of hacking but this is a better option in my opinion. This is because there maybe some user out there who may want to edit other non-computed column values while looking at these computed function values.
Irrespective of the option we chose, users may want to edit delete copy records while viewing these computed function values so these options should be enabled.
Please comment on which option I should choose.
Since I was not entirely sure about option 2. I went ahead with option 1.
https://github.com/phpmyadmin/phpmyadmin/pull/1602/files
Could someone check it is fine?
Aditya,
as Alexander Schuch said ("the first thing..."), the main bug here is that the detection of the presence of a unique column is not correctly done. This is what needs to be fixed here.
https://github.com/phpmyadmin/phpmyadmin/pull/1605
Is this what you meant sir?
Now it even shows this message "Current selection does not contain a unique column. Grid edit, checkbox, Edit, Copy and Delete features are not available."
And this is not correct, as the unique column is shown in the results.
Frankly speaking sir, I don't get it how this problem is related to Unique column detection.
These computed columns may or may not be able to uniquely identify records in a table and irrespective of whether they do, we have to disable grid editing!
Now I am really confused cause PMA uses the table name of the columns to disable edit copy links(line 483 in Displayresults.class.php). That's kind of what I did here too!
Could you please give me a hint what the initial cause of the problem is?
Last edit: Aditya Sastry 2015-03-22
In the example given in "steps" above, the unique column 'id' is shown in the results, which should be sufficient to make the row editable or deletable, regardless of the added computed column.
This should be fixed with https://github.com/phpmyadmin/phpmyadmin/commit/ccca280ea6281a932f42c888c34c0637288ac306
Ported to QA_4_4 https://github.com/phpmyadmin/phpmyadmin/commit/8f58c8f851458b16cc34e9723b3789934c1a8080