[Phpmyadmin-devel] Possible error with ZeroConf and dropping tables
I think I've found an edge case error message when using the ZeroConf feature and removing the phpMyAdmin configuration storage tables. I used the Operations tab of a database with the ZeroConf feature to create the tables. Then, after some time, I decided to drop the tables or entire database. I then get an error about the missing tracking table:
SQL query: DocumentationEdit Edit
SELECT MAX(version) FROM `t_dr`.`pma__tracking` WHERE `db_name` = 't_dr' AND `table_name` = 'pma__bookmark, pma__central_columns, pma__column_info, pma__favorite, pma__history, pma__navigationhiding, pma__pdf_pages, pma__recent, pma__relation, pma__savedsearches, pma__table_coords, pma__table_info, pma__table_uiprefs, pma__tracking, pma__userconfig, pma__usergroups, pma__users' AND FIND_IN_SET('DROP TABLE',tracking) > 0
MySQL said: Documentation #1146 - Table 't_dr.pma__tracking' doesn't exist
This is sort of an edge case but I could see a time when a user wishes to remove the configuration storage tables or database and shouldn't get this error. I've thought of two possible solutions but I'm not sure I like either of them: 1) When dropping a database or table, detect if it's part of the configuration storage and then disable the advanced features. 2) When tracking changes, don't track the configuration storage database or tables. I prefer 2 but I'm not sure about any ramifications of doing so. Any opinions about this?
Isaac Bennetch a écrit :
I think I've found an edge case error message when using the ZeroConf feature and removing the phpMyAdmin configuration storage tables.
I used the Operations tab of a database with the ZeroConf feature to create the tables. Then, after some time, I decided to drop the tables or entire database. I then get an error about the missing tracking table:
SQL query: DocumentationEdit Edit
SELECT MAX(version) FROM `t_dr`.`pma__tracking` WHERE `db_name` = 't_dr' AND `table_name` = 'pma__bookmark, pma__central_columns, pma__column_info, pma__favorite, pma__history, pma__navigationhiding, pma__pdf_pages, pma__recent, pma__relation, pma__savedsearches, pma__table_coords, pma__table_info, pma__table_uiprefs, pma__tracking, pma__userconfig, pma__usergroups, pma__users' AND FIND_IN_SET('DROP TABLE',tracking) > 0
MySQL said: Documentation #1146 - Table 't_dr.pma__tracking' doesn't exist
This is sort of an edge case but I could see a time when a user wishes to remove the configuration storage tables or database and shouldn't get this error. I've thought of two possible solutions but I'm not sure I like either of them: 1) When dropping a database or table, detect if it's part of the configuration storage and then disable the advanced features. 2) When tracking changes, don't track the configuration storage database or tables.
I prefer 2 but I'm not sure about any ramifications of doing so.
Any opinions about this?
Option 2 also has my preference. By the way, this bug maybe also happens when using plain configuration storage (properly configured). -- Marc Delisle (phpMyAdmin)
On Mon, Jan 5, 2015 at 8:32 PM, Isaac Bennetch <bennetch@gmail.com> wrote:
I think I've found an edge case error message when using the ZeroConf feature and removing the phpMyAdmin configuration storage tables.
I used the Operations tab of a database with the ZeroConf feature to create the tables. Then, after some time, I decided to drop the tables or entire database. I then get an error about the missing tracking table:
SQL query: DocumentationEdit Edit
SELECT MAX(version) FROM `t_dr`.`pma__tracking` WHERE `db_name` = 't_dr' AND `table_name` = 'pma__bookmark, pma__central_columns, pma__column_info, pma__favorite, pma__history, pma__navigationhiding, pma__pdf_pages, pma__recent, pma__relation, pma__savedsearches, pma__table_coords, pma__table_info, pma__table_uiprefs, pma__tracking, pma__userconfig, pma__usergroups, pma__users' AND FIND_IN_SET('DROP TABLE',tracking) > 0
MySQL said: Documentation #1146 - Table 't_dr.pma__tracking' doesn't exist
This is sort of an edge case but I could see a time when a user wishes to remove the configuration storage tables or database and shouldn't get this error. I've thought of two possible solutions but I'm not sure I like either of them: 1) When dropping a database or table, detect if it's part of the configuration storage and then disable the advanced features. 2) When tracking changes, don't track the configuration storage database or tables.
I prefer 2 but I'm not sure about any ramifications of doing so.
Any opinions about this?
Option 1 should be the proper way to handle this. I'm not sure option 2 would work because MySQL would still complain about missing tracking table when trying to get tracking data for another table.
-- Thanks and Regards, Madhura Jayaratne
participants (3)
-
Isaac Bennetch -
Madhura Jayaratne -
Marc Delisle