[Phpmyadmin-devel] permanent storage feature done - please provide your feedback
Hello, everyone, I have uploaded the final revision<https://sourceforge.net/tracker/index.php?func=detail&aid=2825187&group_id=23067&atid=377410>for permanent storage feature. I would appreciate if members of the community can test it, and provide me with their valuable feedback. This final revision will allow you to update following settings straight form your browser: - naviWidth - maxRows - foreignKeyMaxLimit - propertiesIconic - propertiesNumColumns - leftFrameLight - useDbSearch - maxDbList - maxTableList - fullText - loginCookieValidity - navBarIconic I hope my work helps the community, and phpmyadmin's users find it worthy of their use. Also, I would appreciate if someone from the developers team can assign him to the patch. Thanks so much for the cooperation! -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info
Hi Dne Tue, 11 Aug 2009 03:35:22 -0400 Zeeshan Mughal <zeeshanmughal@ieee.org> napsal(a):
I hope my work helps the community, and phpmyadmin's users find it worthy of their use. Also, I would appreciate if someone from the developers team can assign him to the patch.
First, the patch does not apply: refs_final.patch (Stripping trailing CRs from patch.) patching file db_search.php (Stripping trailing CRs from patch.) patching file db_structure.php (Stripping trailing CRs from patch.) patching file index.php (Stripping trailing CRs from patch.) patching file lang/english-utf-8.inc.php Hunk #1 succeeded at 1 with fuzz 2. (Stripping trailing CRs from patch.) patching file libraries/auth/cookie.auth.lib.php (Stripping trailing CRs from patch.) patching file libraries/config.default.php (Stripping trailing CRs from patch.) patching file libraries/db_perm.usr.pref.php (Stripping trailing CRs from patch.) patching file libraries/db_structure.lib.php (Stripping trailing CRs from patch.) patching file libraries/display_tbl.lib.php (Stripping trailing CRs from patch.) patching file libraries/footer.inc.php patch: **** malformed patch at line 541: + } else { Also please remove not needed things from the patch: //$cfg['LoginCookieValidity'] = 4646464654654564564654648645645456564465464; var $link = ''; in permUsrPref class Other comments: permUsrPref class should be named PMA_PermUsrPref and it should be defined in libraries/PermUsrPref.class.php permUsrPref.table should not be hardcoded, but configurable You should really use PMA_query_as_controluser You copy the same code to several places, it should be rather single include which would provide all what is needed to access preferences. * @TODO Figure out why SQL queries do not give proper results - this means that your code does not work? -- Michal Čihař | http://cihar.com | http://blog.cihar.com
* @TODO Figure out why SQL queries do not give proper results - this means that your code does not work?
This is actually very old. So, please ignore it. Thanks for the comments. -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Tue, Aug 11, 2009 at 4:11 AM, Michal Čihař <michal@cihar.com> wrote:
Hi
Dne Tue, 11 Aug 2009 03:35:22 -0400 Zeeshan Mughal <zeeshanmughal@ieee.org> napsal(a):
I hope my work helps the community, and phpmyadmin's users find it worthy of their use. Also, I would appreciate if someone from the developers team can assign him to the patch.
First, the patch does not apply:
refs_final.patch (Stripping trailing CRs from patch.) patching file db_search.php (Stripping trailing CRs from patch.) patching file db_structure.php (Stripping trailing CRs from patch.) patching file index.php (Stripping trailing CRs from patch.) patching file lang/english-utf-8.inc.php Hunk #1 succeeded at 1 with fuzz 2. (Stripping trailing CRs from patch.) patching file libraries/auth/cookie.auth.lib.php (Stripping trailing CRs from patch.) patching file libraries/config.default.php (Stripping trailing CRs from patch.) patching file libraries/db_perm.usr.pref.php (Stripping trailing CRs from patch.) patching file libraries/db_structure.lib.php (Stripping trailing CRs from patch.) patching file libraries/display_tbl.lib.php (Stripping trailing CRs from patch.) patching file libraries/footer.inc.php patch: **** malformed patch at line 541: + } else {
Also please remove not needed things from the patch:
//$cfg['LoginCookieValidity'] = 4646464654654564564654648645645456564465464;
var $link = ''; in permUsrPref class
Other comments:
permUsrPref class should be named PMA_PermUsrPref and it should be defined in libraries/PermUsrPref.class.php
permUsrPref.table should not be hardcoded, but configurable
You should really use PMA_query_as_controluser
You copy the same code to several places, it should be rather single include which would provide all what is needed to access preferences.
* @TODO Figure out why SQL queries do not give proper results - this means that your code does not work?
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Dne Tue, 11 Aug 2009 12:57:40 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
* @TODO Figure out why SQL queries do not give proper results - this means that your code does not work?
This is actually very old. So, please ignore it.
Well I don't care whether it is old or not. It is in thing which you have called "final revision". All I can say is that is really not something what looks like finished and cleaned up work. And it is definitely not ready for inclusion. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Hi,
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
permUsrPref class should be named PMA_PermUsrPref and it should be defined in libraries/PermUsrPref.class.php
done
You should really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for SELECT I get errors. [1] Following line of code demonstrates how I am implementing PMA_query_as_controluser: return PMA_DBI_fetch_result(PMA_query_as_controluser($sql)); I have also commented out implementation of PMA_query_as_controluser in ./libraries/PermUsrPreg.class.php just in case if you were interested in seeing.
You copy the same code to several places, it should be rather single include which would provide all what is needed to access preferences.
I created a function in ./libraries/common.lib.php to include common files. Please let me know if there are further improvements you can suggest on this issue. I also tried to include: /* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref(); but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
All I can say is that is really not something what looks like finished and cleaned up work. And it is definitely not ready for inclusion.
Well, that is why I need feedback from phpMyAdmin gurus (like you) so I can fix such problems (sometimes lame) before the code is committed. :-) You can download the revision<https://sourceforge.net/tracker/index.php?func=detail&aid=2825187&group_id=23067&atid=377410#>through tracker. Thanks so much for you help! I highly appreciate your time and dedication. :-) [0] http://www.nabble.com/about-choosing-table-layout-for-pmadb-td23879613.html<http://www.nabble.com/about-choosing-table-layout-for-pmadb-td23879613.html#a23879613> [1] http://zixan.info/pma/pma_error.html.0-dev -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Tue, Aug 11, 2009 at 5:07 PM, Michal Čihař <michal@cihar.com> wrote:
Dne Tue, 11 Aug 2009 12:57:40 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
* @TODO Figure out why SQL queries do not give proper results - this means that your code does not work?
This is actually very old. So, please ignore it.
Well I don't care whether it is old or not. It is in thing which you have called "final revision". All I can say is that is really not something what looks like finished and cleaned up work. And it is definitely not ready for inclusion.
-- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Just a though hit my mind about having $pma_usr_prefs = new PMA_PermUsrPref(); in common.lib.php. I am wondering may be it should be declared as a global var. -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Wed, Aug 12, 2009 at 2:12 AM, Zeeshan M. <zeeshan.jp@gmail.com> wrote:
Hi,
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
permUsrPref class should be named PMA_PermUsrPref and it should be defined in libraries/PermUsrPref.class.php
done
You should really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for SELECT I get errors. [1] Following line of code demonstrates how I am implementing PMA_query_as_controluser:
return PMA_DBI_fetch_result(PMA_query_as_controluser($sql));
I have also commented out implementation of PMA_query_as_controluser in ./libraries/PermUsrPreg.class.php just in case if you were interested in seeing.
You copy the same code to several places, it should be rather single include which would provide all what is needed to access preferences.
I created a function in ./libraries/common.lib.php to include common files. Please let me know if there are further improvements you can suggest on this issue.
I also tried to include:
/* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
All I can say is that is really not something what looks like finished and cleaned up work. And it is definitely not ready for inclusion.
Well, that is why I need feedback from phpMyAdmin gurus (like you) so I can fix such problems (sometimes lame) before the code is committed. :-)
You can download the revision<https://sourceforge.net/tracker/index.php?func=detail&aid=2825187&group_id=23067&atid=377410#>through tracker.
Thanks so much for you help! I highly appreciate your time and dedication. :-)
[0] http://www.nabble.com/about-choosing-table-layout-for-pmadb-td23879613.html<http://www.nabble.com/about-choosing-table-layout-for-pmadb-td23879613.html#a23879613> [1] http://zixan.info/pma/pma_error.html.0-dev -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info
On Tue, Aug 11, 2009 at 5:07 PM, Michal Čihař <michal@cihar.com> wrote:
Dne Tue, 11 Aug 2009 12:57:40 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
* @TODO Figure out why SQL queries do not give proper results - this means that your code does not work?
This is actually very old. So, please ignore it.
Well I don't care whether it is old or not. It is in thing which you have called "final revision". All I can say is that is really not something what looks like finished and cleaned up work. And it is definitely not ready for inclusion.
-- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 12.08.2009 08:12, Zeeshan M. wrote:
Hi,
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
i think he was talking about using a config variable to store the table name and hard code it, just like other pma tables: http://wiki.phpmyadmin.net/pma/Config#pmadb
You copy the same code to several places, it should be rather single include which would provide all what is needed to access preferences.
I created a function in ./libraries/common.lib.php to include common files. Please let me know if there are further improvements you can suggest on this issue.
I also tried to include:
/* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
you should try to replace this: + +/* + * Include common files required by Permanent Storage feature + */ +PMA_permUsrPref(); + +/* + * Creates a $pma_usr_prefs pointer + */ +$pma_usr_prefs = new PMA_PermUsrPref(); + +/* + * Fetch current setting for $cfg['PropertiesNumColumns'] from pmadb + */ + + $propertiesNumColumns = $pma_usr_prefs->fetchSettingValue('propertiesNumColumns'); + +if ($isUsrPrefsEnabled) { + $GLOBALS['cfg']['PropertiesNumColumns'] = $cfg['PropertiesNumColumns'] = $propertiesNumColumns[0]; +} + +unset($pma_usr_prefs); + with a single function call, e. g.: $GLOBALS['cfg']['PropertiesNumColumns'] = PMA_permUsrPrefGet('PropertiesNumColumns'); -- Sebastian
On 12.08.2009 09:06, Sebastian Mendel wrote:
On 12.08.2009 08:12, Zeeshan M. wrote:
Hi,
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
i think he was talking about using a config variable to store the table name and hard code it, just like other pma tables:
ups: "and _not_ hard code it"
-- Sebastian Mendel
Hi Dne Wed, 12 Aug 2009 02:12:43 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
I mean table name, like Sebastian already has explained.
You should really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for SELECT I get errors. [1] Following line of code demonstrates how I am implementing PMA_query_as_controluser:
return PMA_DBI_fetch_result(PMA_query_as_controluser($sql));
You need to add flags PMA_DBI_QUERY_STORE to query if you want to fetch whole result at once.
I also tried to include:
/* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
And what's reason for creating class and function of same name? I think you could use similar way like we use for relation stuff. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Thanks for the comments. Did anyone actually try running the code? Any feedback on overall outlook of interface? Anything else you can suggest about user interaction? Did you find any errors and/or warnings? I am asking this as one might see different results based on the server code is running on. Thanks. -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Wed, Aug 12, 2009 at 4:08 AM, Michal Čihař <michal@cihar.com> wrote:
Hi
Dne Wed, 12 Aug 2009 02:12:43 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers. Please correct me if I am wrong, or you are referring to something else by "configurable".
I mean table name, like Sebastian already has explained.
You should really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for SELECT I get errors. [1] Following line of code demonstrates how I am implementing PMA_query_as_controluser:
return PMA_DBI_fetch_result(PMA_query_as_controluser($sql));
You need to add flags PMA_DBI_QUERY_STORE to query if you want to fetch whole result at once.
I also tried to include:
/* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
And what's reason for creating class and function of same name?
I think you could use similar way like we use for relation stuff.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi Dne Wed, 12 Aug 2009 12:10:31 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
Thanks for the comments.
Did anyone actually try running the code? Any feedback on overall outlook of interface? Anything else you can suggest about user interaction?
Did you find any errors and/or warnings? I am asking this as one might see different results based on the server code is running on.
I did not run the code so far, because first version of final patch failed to apply and I did not have time to test second version so far. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
you should try to replace this .... with a single function call, e. g.: $GLOBALS['cfg']['PropertiesNumColumns'] = PMA_permUsrPrefGet('PropertiesNumColumns');
This would help put the code in one central location. This is probably better than having the code scattered all over. But I don't think it would help reduce the amount of code being written, if it were one of the goals. Some of the settings are not directly applied to global config vars so they have to go through conditional statements.
I mean table name, like Sebastian already has explained.
Sure. Thanks Sebastian!
You need to add flags PMA_DBI_QUERY_STORE to query if you want to fetch whole result at once.
I am SELECTing in the following format, and I still get the same error. Does it require modifications? return PMA_DBI_fetch_result(PMA_query_as_controluser($sql),PMA_DBI_QUERY_STORE)
I think you could use similar way like we use for relation stuff.
Sweet. Convention used to name functions in relation.lib.php probably makes more sense. -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Wed, Aug 12, 2009 at 4:08 AM, Michal Čihař <michal@cihar.com> wrote:
Hi
Dne Wed, 12 Aug 2009 02:12:43 -0400 "Zeeshan M." <zeeshan.jp@gmail.com> napsal(a):
permUsrPref.table should not be hardcoded, but configurable
I think we discussed this a long time back. [0] I suppose EAV model had "design flaws" as suggested by Marc Delisle, and other developers.
Please
correct me if I am wrong, or you are referring to something else by "configurable".
I mean table name, like Sebastian already has explained.
You should really use PMA_query_as_controluser
I can use PMA_query_as_controluser for UPDATE query. But when I use it for SELECT I get errors. [1] Following line of code demonstrates how I am implementing PMA_query_as_controluser:
return PMA_DBI_fetch_result(PMA_query_as_controluser($sql));
You need to add flags PMA_DBI_QUERY_STORE to query if you want to fetch whole result at once.
I also tried to include:
/* * Creates a $pma_usr_prefs pointer */ $pma_usr_prefs = new PMA_PermUsrPref();
but it seems it is not being recognized as an object because of being remotely included in a standalone function: *Fatal error*: Call to a member function fetchSettingValue() on a non-object
And what's reason for creating class and function of same name?
I think you could use similar way like we use for relation stuff.
-- Michal Čihař | http://cihar.com | http://blog.cihar.com
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 13.08.2009 07:21, Zeeshan M. wrote:
you should try to replace this .... with a single function call, e. g.: $GLOBALS['cfg']['PropertiesNumColumns'] = PMA_permUsrPrefGet('PropertiesNumColumns');
This would help put the code in one central location. This is probably better than having the code scattered all over.
yes
But I don't think it would help reduce the amount of code being written, if it were one of the goals. Some of the settings are not directly applied to global config vars so they have to go through conditional statements.
btw. why do you not just apply all user settings at once? i am not familiar with the detailed current handling of configuration in the session, but IMHO this should only be required once per session even if this is not an option, in most cases you set only one user option and this could be done with a single function call i would suggest include the user pref class in common.inc.php and apply all user settings at once, additionally i would move all related code into the class (except the initial call of course) Michal, what do you think? -- Sebastian Mendel
i am not familiar with the detailed current handling of configuration in the session, but IMHO this should only be required once per session
Great idea, Sebastian! Fetching settings from db only once per session would be vital in decreasing server load and further increasing performance. I believe Marc Delisle also suggested this. I will see how I can go about implementing this. Thanks! Also, I found a minor bug in my code. Extracted db value for LoginCookieValidity turns out to be non-INT type by default. So, if you have tried running the script, you may have realized that your session breaks in less than expected time. Multiplying db value by 1 should do the trick. -------------------------------------------------- Best regards, Zeeshan Mughal Email: zeeshanmughal@ieee.org Web: http://www.zixan.info On Thu, Aug 13, 2009 at 2:08 AM, Sebastian Mendel <lists@sebastianmendel.de> wrote:
On 13.08.2009 07:21, Zeeshan M. wrote:
you should try to replace this .... with a single function call, e. g.: $GLOBALS['cfg']['PropertiesNumColumns'] = PMA_permUsrPrefGet('PropertiesNumColumns');
This would help put the code in one central location. This is probably better than having the code scattered all over.
yes
But I don't think it would help reduce the amount of code being written, if it were one of the goals. Some of the settings are not directly applied to global config vars so they have to go through conditional statements.
btw. why do you not just apply all user settings at once?
i am not familiar with the detailed current handling of configuration in the session, but IMHO this should only be required once per session
even if this is not an option, in most cases you set only one user option and this could be done with a single function call
i would suggest include the user pref class in common.inc.php and apply all user settings at once, additionally i would move all related code into the class (except the initial call of course)
Michal, what do you think?
-- Sebastian Mendel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 13.08.2009 21:57, Zeeshan M. wrote:
Also, I found a minor bug in my code. Extracted db value for LoginCookieValidity turns out to be non-INT type by default.
all Variables from $_REQUEST (_COOKIE, _GET, _POST) are strings
So, if you have tried running the script, you may have realized that your session breaks in less than expected time. Multiplying db value by 1 should do the trick.
use $myVar = (int) $myVar; or $myVar = intval($myVar); -- Sebastian Mendel
participants (4)
-
Michal Čihař -
Sebastian Mendel -
Zeeshan M. -
Zeeshan Mughal