Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/ (Zeroconf PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/ (Zeroconf PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
* The solution has to work for a single-user installation and also for a multi-user installation
* Priority should go to use the values from config.inc.php (the control user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
* In case there is no such configuration, the logic could check the presence of the default database name and table names, as suggested in examples/create_tables.sql
* I'm not sure on which panel is the best place to do this verification, but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
* If this default database name "phpmyadmin" does not exist, the logic could look for the default table names in the current database (this is in case the user has access to only one database)
* If the default db and/or default table names are not found, the logic could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
* Something will have to be done with the logic that gives a warning about the configuration storage; it would probably lose its purpose
* Maybe we'll need a new directive in config.inc.php, so that the installer can decide that the zero conf is active or not (would be active by default)
* I am not in favor of designing a UI to set up the configuration storage, as this already exists in /setup (with the goal of producing a config.inc.php)
* I am not in favor of programmatically creating a .php file in the installation directory or doing any modification in config.inc.php
Hi, I quite agree with what Marc said, but I have a few thoughts in-line below:
On 8/5/14, 5:16 PM, Marc Delisle wrote:
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/ (Zeroconf PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
- The solution has to work for a single-user installation and also for a
multi-user installation
- Priority should go to use the values from config.inc.php (the control
user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
- In case there is no such configuration, the logic could check the
presence of the default database name and table names, as suggested in examples/create_tables.sql
- I'm not sure on which panel is the best place to do this verification,
but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
This makes the most sense to me as well.
- If this default database name "phpmyadmin" does not exist, the logic
could look for the default table names in the current database (this is in case the user has access to only one database)
- If the default db and/or default table names are not found, the logic
could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
- Something will have to be done with the logic that gives a warning
about the configuration storage; it would probably lose its purpose
- Maybe we'll need a new directive in config.inc.php, so that the
installer can decide that the zero conf is active or not (would be active by default)
This is probably best.
- I am not in favor of designing a UI to set up the configuration
storage, as this already exists in /setup (with the goal of producing a config.inc.php)
I agree.
- I am not in favor of programmatically creating a .php file in the
installation directory or doing any modification in config.inc.php
I also agree with this.
On Wed, Aug 6, 2014 at 2:46 AM, Marc Delisle marc@infomarc.info wrote:
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/ (Zeroconf PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
Thanks Marc and Isaac.
The RFE was a bit confusing but the insight provided by you both clarified everything. However, I have a few queries and I am posting them in-line.
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
- The solution has to work for a single-user installation and also for a
multi-user installation
How single-user and multi-user installation is going to affect this feature? Is it something like if the user does not have access to the database defined in the directive $cfg['Servers'][$i]['pmadb'], then create the pma tables in the database on which he/she has access?
- Priority should go to use the values from config.inc.php (the control
user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
- In case there is no such configuration, the logic could check the
presence of the default database name and table names, as suggested in examples/create_tables.sql
- I'm not sure on which panel is the best place to do this verification,
but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
- If this default database name "phpmyadmin" does not exist, the logic
could look for the default table names in the current database (this is in case the user has access to only one database)
Lets say user sees the warning on homepage. Then how to decide the current db? Is it something like creating these tables in the first database on which the user has CREATE access?
- If the default db and/or default table names are not found, the logic
could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
- Something will have to be done with the logic that gives a warning
about the configuration storage; it would probably lose its purpose
Yes Marc. We will have to do something for this. How about keeping this message/warning intact and when the user clicks on 'here' of "To find out why click here http://127.0.0.1/pma/chk_rel.php?token=ee04c7e45192bb15a4151248028e905f.", the user will be directed to diagnostic page as it is currently done. And on that page we can provide a link with text something like "Fix it" and when user will click this link, the new logic will be executed?
- Maybe we'll need a new directive in config.inc.php, so that the
installer can decide that the zero conf is active or not (would be active by default)
- I am not in favor of designing a UI to set up the configuration
storage, as this already exists in /setup (with the goal of producing a config.inc.php)
- I am not in favor of programmatically creating a .php file in the
installation directory or doing any modification in config.inc.php
Ashutosh Dhundhara a écrit :
On Wed, Aug 6, 2014 at 2:46 AM, Marc Delisle marc@infomarc.info wrote:
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/ (Zeroconf PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
Thanks Marc and Isaac.
The RFE was a bit confusing but the insight provided by you both clarified everything. However, I have a few queries and I am posting them in-line.
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
- The solution has to work for a single-user installation and also for a
multi-user installation
How single-user and multi-user installation is going to affect this feature? Is it something like if the user does not have access to the database defined in the directive $cfg['Servers'][$i]['pmadb'], then create the pma tables in the database on which he/she has access?
It is current for a single-user installation to not bother creating a control user; when there is no control user, the logged-in user is used also to access the pmadb.
In a multi-user installation, there is normally a distinct control user defined.
So please test both situations.
- Priority should go to use the values from config.inc.php (the control
user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
- In case there is no such configuration, the logic could check the
presence of the default database name and table names, as suggested in examples/create_tables.sql
- I'm not sure on which panel is the best place to do this verification,
but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
- If this default database name "phpmyadmin" does not exist, the logic
could look for the default table names in the current database (this is in case the user has access to only one database)
Lets say user sees the warning on homepage. Then how to decide the current db?
Good question; so probably the verification won't be possible from the home page, only from a db-specific Operations page.
Anyway, we could not ask the user to choose a db to store the configuration storage, because this choice could not be remembered (as this is a zero-conf mechanism).
Is it something like creating these tables in the first database on which the user has CREATE access?
No, because it won't be possible to know which db contains the configuration storage, when the user opens another database.
- If the default db and/or default table names are not found, the logic
could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
- Something will have to be done with the logic that gives a warning
about the configuration storage; it would probably lose its purpose
Yes Marc. We will have to do something for this. How about keeping this message/warning intact and when the user clicks on 'here' of "To find out why click here http://127.0.0.1/pma/chk_rel.php?token=ee04c7e45192bb15a4151248028e905f.", the user will be directed to diagnostic page as it is currently done. And on that page we can provide a link with text something like "Fix it" and when user will click this link, the new logic will be executed?
Good idea. This way, either the user can fix it manually (in a way that permits to have just one configuration storage) but will require configuration, or will be able to use the zero-conf mechanism (which will produce the pma_ tables in his current db).
- Maybe we'll need a new directive in config.inc.php, so that the
installer can decide that the zero conf is active or not (would be active by default)
- I am not in favor of designing a UI to set up the configuration
storage, as this already exists in /setup (with the goal of producing a config.inc.php)
- I am not in favor of programmatically creating a .php file in the
installation directory or doing any modification in config.inc.php
On Fri, Aug 8, 2014 at 12:37 AM, Marc Delisle marc@infomarc.info wrote:
Ashutosh Dhundhara a écrit :
On Wed, Aug 6, 2014 at 2:46 AM, Marc Delisle marc@infomarc.info wrote:
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/
(Zeroconf
PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
Thanks Marc and Isaac.
The RFE was a bit confusing but the insight provided by you both
clarified
everything. However, I have a few queries and I am posting them in-line.
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
- The solution has to work for a single-user installation and also for a
multi-user installation
How single-user and multi-user installation is going to affect this
feature?
Is it something like if the user does not have access to the database defined in the directive $cfg['Servers'][$i]['pmadb'], then create the pma tables in the database on which he/she has access?
It is current for a single-user installation to not bother creating a control user; when there is no control user, the logged-in user is used also to access the pmadb.
In a multi-user installation, there is normally a distinct control user defined.
So please test both situations.
- Priority should go to use the values from config.inc.php (the control
user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
- In case there is no such configuration, the logic could check the
presence of the default database name and table names, as suggested in examples/create_tables.sql
- I'm not sure on which panel is the best place to do this verification,
but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
- If this default database name "phpmyadmin" does not exist, the logic
could look for the default table names in the current database (this is in case the user has access to only one database)
Lets say user sees the warning on homepage. Then how to decide the
current
db?
Good question; so probably the verification won't be possible from the home page, only from a db-specific Operations page.
Anyway, we could not ask the user to choose a db to store the configuration storage, because this choice could not be remembered (as this is a zero-conf mechanism).
Is it something like creating these tables in the first database on which the user has CREATE access?
No, because it won't be possible to know which db contains the configuration storage, when the user opens another database.
- If the default db and/or default table names are not found, the logic
could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
- Something will have to be done with the logic that gives a warning
about the configuration storage; it would probably lose its purpose
Yes Marc. We will have to do something for this. How about keeping this message/warning intact and when the user clicks on 'here' of "To find out why click here <http://127.0.0.1/pma/chk_rel.php?token=ee04c7e45192bb15a4151248028e905f .", the user will be directed to diagnostic page as it is currently done. And on that page we can provide a link with text something like "Fix it" and when
user
will click this link, the new logic will be executed?
Good idea. This way, either the user can fix it manually (in a way that permits to have just one configuration storage) but will require configuration, or will be able to use the zero-conf mechanism (which will produce the pma_ tables in his current db).
- Maybe we'll need a new directive in config.inc.php, so that the
installer can decide that the zero conf is active or not (would be active by default)
- I am not in favor of designing a UI to set up the configuration
storage, as this already exists in /setup (with the goal of producing a config.inc.php)
- I am not in favor of programmatically creating a .php file in the
installation directory or doing any modification in config.inc.php
Hi Marc,
What if a user has access to multiple databases and the default database 'phpmyadmin' does not exists? Lets say the user visits database 1 > Operation tab where he agrees to the choice to create pma tables in that database.
Now for the current session the configuration storage is up and working. Now when next time he logs into PMA, there will be again a warning for configuration storage on home page. But when he will visit database 1 > Operation tab, everything will become fine again.
But what if he visits database 2 > Operation tab before database 1. He will get a choice to create pma tables in that database too. If he agrees to create then there will be two different sets of pma tables because pmadb name can't be remembered. What should be done in this case?
Ashutosh Dhundhara a écrit :
On Fri, Aug 8, 2014 at 12:37 AM, Marc Delisle marc@infomarc.info wrote:
Ashutosh Dhundhara a écrit :
On Wed, Aug 6, 2014 at 2:46 AM, Marc Delisle marc@infomarc.info wrote:
Le 2014-08-05 14:35, Ashutosh Dhundhara a écrit :
Hi,
I was starting to work on RFE #1123 https://sourceforge.net/p/phpmyadmin/feature-requests/1123/
(Zeroconf
PMA tables support).
Is it something like enabling/disabling the PMA configuration storage feature through UI with default table names?
Also, automatically create these tables when user has enabled this feature through UI?
Hi Ashutosh,
Thanks Marc and Isaac.
The RFE was a bit confusing but the insight provided by you both
clarified
everything. However, I have a few queries and I am posting them in-line.
I have read again the RFE and the comments in the ticket; then I read the details of your proposal on google-melange.com.
I don't have all the answers but can give you some pointers; others can give ideas too or contradict mine :)
- The solution has to work for a single-user installation and also for a
multi-user installation
How single-user and multi-user installation is going to affect this
feature?
Is it something like if the user does not have access to the database defined in the directive $cfg['Servers'][$i]['pmadb'], then create the pma tables in the database on which he/she has access?
It is current for a single-user installation to not bother creating a control user; when there is no control user, the logged-in user is used also to access the pmadb.
In a multi-user installation, there is normally a distinct control user defined.
So please test both situations.
- Priority should go to use the values from config.inc.php (the control
user, pmadb and all pmadb tables) if present. This is mainly for backward compatibility and also because I suspect it's the only way to support a multi-user installation
- In case there is no such configuration, the logic could check the
presence of the default database name and table names, as suggested in examples/create_tables.sql
- I'm not sure on which panel is the best place to do this verification,
but it could be at the same places where the warnings about the configuration storage are currently done (home page and each database > Operations page
- If this default database name "phpmyadmin" does not exist, the logic
could look for the default table names in the current database (this is in case the user has access to only one database)
Lets say user sees the warning on homepage. Then how to decide the
current
db?
Good question; so probably the verification won't be possible from the home page, only from a db-specific Operations page.
Anyway, we could not ask the user to choose a db to store the configuration storage, because this choice could not be remembered (as this is a zero-conf mechanism).
Is it something like creating these tables in the first database on which the user has CREATE access?
No, because it won't be possible to know which db contains the configuration storage, when the user opens another database.
- If the default db and/or default table names are not found, the logic
could pop a dialog, offering to create these in the current db and asking for confirmation; I hope it's possible to directly read examples/create_tables.sql for this, in order to avoid discrepancies between the logic and changes in create_tables.sql
- Something will have to be done with the logic that gives a warning
about the configuration storage; it would probably lose its purpose
Yes Marc. We will have to do something for this. How about keeping this message/warning intact and when the user clicks on 'here' of "To find out why click here <http://127.0.0.1/pma/chk_rel.php?token=ee04c7e45192bb15a4151248028e905f .", the user will be directed to diagnostic page as it is currently done. And on that page we can provide a link with text something like "Fix it" and when
user
will click this link, the new logic will be executed?
Good idea. This way, either the user can fix it manually (in a way that permits to have just one configuration storage) but will require configuration, or will be able to use the zero-conf mechanism (which will produce the pma_ tables in his current db).
- Maybe we'll need a new directive in config.inc.php, so that the
installer can decide that the zero conf is active or not (would be active by default)
- I am not in favor of designing a UI to set up the configuration
storage, as this already exists in /setup (with the goal of producing a config.inc.php)
- I am not in favor of programmatically creating a .php file in the
installation directory or doing any modification in config.inc.php
Hi Marc,
What if a user has access to multiple databases and the default database 'phpmyadmin' does not exists? Lets say the user visits database 1 > Operation tab where he agrees to the choice to create pma tables in that database.
Now for the current session the configuration storage is up and working. Now when next time he logs into PMA, there will be again a warning for configuration storage on home page. But when he will visit database 1 > Operation tab, everything will become fine again.
Hi Ashutosh, I said above "probably the verification won't be possible from the home page, only from a db-specific Operations page".
But what if he visits database 2 > Operation tab before database 1. He will get a choice to create pma tables in that database too. If he agrees to create then there will be two different sets of pma tables because pmadb name can't be remembered. What should be done in this case?
I don't think that we can further help this user; he will have to use different sets of the phpMyAdmin configuration storage. There is no zero-conf way of remembering which db contains thess tables. Doing a search in each db the user has access to, to find a set of configuration storage tables, is not a good idea.
However, when creating the set in db1, we should give the user a warning that this set will only apply to this database, and that to have just one set, he should follow the doc explaining this.
-
Ashutosh Dhundhara -
Isaac Bennetch -
Marc Delisle