On Tue, 9 Apr 2002, Marc Delisle wrote:
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).
Yes, that is how I was considering doing it.
But there is one additional layer I had considered.
In the initial load of variables, we would do them in this order: 1. load variables from configuration file (base defaults and username/password for database access initially). 2. if configuration type is database, read in config_master 3. if configuration global allow user override, read in config_user on fields that have allow_override set in the config_master table. 4. in the config_user table, if allow_override is set, then the user can change that preference on their own. Otherwise the admin must set it for the 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?
Yes. it would be good.
Maybe a third field to indicate if this can be overriden by the user (indicating a possible search in config_user).
Here are my two table structures that I have been playing around with:
CREATE TABLE config_master ( option VARCHAR(255) NOT NULL DEFAULT '', value TEXT, allow_override BOOL NOT NULL DEFAULT '0', PRIMARY KEY (option), KEY allow_override (allow_override) ) TYPE=MyISAM COMMENT='Master Configuration Options';
CREATE TABLE config_user ( user VARCHAR(255) NOT NULL DEFAULT '', option VARCHAR(255) NOT NULL DEFAULT '', value TEXT, allow_override BOOL NOT NULL DEFAULT '0', PRIMARY KEY (option), KEY allow_override (allow_override) ) TYPE=MyISAM COMMENT='User Configuration Options';
Looking at this, there are some questions I have, for people. should the 'value' column be BLOB type or TEXT type? How large will the data be? Could we shring it to TINYTEXT/BLOB or VARCHAR(255) ?
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.
Ok.
For security reasons, I also propose doing away with the 'only_db' option, as it is only a very poor substituate for proper user rights in MySQL.