[Phpmyadmin-devel] official domain name phpmyadmin.net
DelislMa at CollegeSherbrooke.qc.ca
Tue Apr 9 10:01:02 CEST 2002
Robin Johnson a écrit :
> On Mon, 8 Apr 2002, Marc Delisle wrote:
> > I am not against using functions, but:
> > - what about the existing arrays in config.inc.php3?
> That is the reason I was using serialize and unserialize to store the
> data. Those functions preserve arrays perfectly.
> > - implementing pma_getvariable() all over the code will be a lot of
> > work, so I suggest before starting this, to think also about a possible
> > User Preferences module (db-stored also).
> Could we decide on which of the options in the current configuration
> should be available to each user in their personal preferences?
For example, let's talk about $cfgShowBlob and assume that this can be
a master and a user pref.
I guess you have put a "ShowBlob" field in the config_master table.
It would be more flexible not to have the actual cfg variable names
as fields, but as data, so the config_master table would have 2 fields:
the cfg variable name, and the cfg variable value (possibly serialized).
Maybe a third field to indicate if this can be overriden by the user
(indicating a possible search in config_user).
This is because we have to think about future PMA upgrades and avoid
users having to add fields to config_master.
What do you think of that?
> Since it will just be the redefinition of some of the options from the
> main configuration, I propose doing it like this:
> Read in the master 'config_master' table.
> Read in a client override table 'config_user' which is contains all the
> fields of 'config_master' plus one additional field for the username.
> The options for 'config_user' are set over the existing 'config_master'
> Voila! You have user preferences. But we would need to put some security
> on that 'config_user' table, as there are probably some things that we do
> not want the user being able to change.
> Also, looking at the security functions of this, as well as the speed
> considerations, using a database configuration system will REQUIRE a
> system that supports sessions, otherwise you risk poor performance
> (re-reading the configuration data on each page). By using sessions, it
> could be loaded once on login, and then re-loaded if the user changes
It is ok for me to require sessions for this, you are right about performance,
and also because this will be an optional configuration mecanism.
Keep on the good work!
More information about the Developers