Hi All!
Well first I would like to warn you that serialize/unserialize functions are buggy with some php4 releases. This is the case till 4.0.6 (as far as I remember) with objects but it's also the case with complex arrays (I mean associative ones) at least with one of the php release I can't remember the number. Check the official php bug tracker to find it.
In the initial load of variables, we would do them in this order:
- load variables from configuration file (base defaults and....
This scheme sounds right to me.
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:
Weel using MyISAM table type and a comment for it means they can only be used for MySQL 3.23.... revisions.
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) ?
IMHO TEXT type is required, even if a varchar sounds enough at this time: using TEXT will allow us to add as much settings as we want later without having to change the table structure.
I also agree with sessions but we must be warn that it'll be a hard work to take into account each possible php configuration.
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.
I agree, it's a "very poor substituate" BUT I can't imagine an other way to do it. We already have widely debated about the "SHOW GRANTS" limits in one hand, we can't rely neither on the "SHOW DATABASE" query neither on the "mysql_db_list" function on the other hand (since lots of shared server disable this features for security and server charge reasons). That's a real and annoying problem...
Loïc
______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
On Wed, 10 Apr 2002, Lo�c wrote:
Well first I would like to warn you that serialize/unserialize functions are buggy with some php4 releases. This is the case till 4.0.6 (as far as I remember) with objects but it's also the case with complex arrays (I mean associative ones) at least with one of the php release I can't remember the number. Check the official php bug tracker to find it.
I have looked thru the bug tracker, and all that I see is that arrays with references in them have serious problems. Two dimensonal arrays and all the other things that we use in the PMA configuration are fine.
Here are my two table structures that I have been playing around with:
Weel using MyISAM table type and a comment for it means they can only be used for MySQL 3.23.... revisions.
Comments were added in 3.23.0. So basically all of 3.23 is safe for using comments on tables.
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) ?
IMHO TEXT type is required, even if a varchar sounds enough at this time: using TEXT will allow us to add as much settings as we want later without having to change the table structure.
The other question with it, is the question of is serialize gaurenteed to return strings for use in TEXT, or does it return binary data that needs BLOB?
I also agree with sessions but we must be warn that it'll be a hard work to take into account each possible php configuration.
There is something else I have been working on in PHP, basically a bit of code you throw at the start of a page, that handles however those sessions were set, no matter what the PHP configuration options are. Additionally, I am working with using the PHP CVS presently, on Apache2. In looking at the changes in how PHP works from PHP 4.0 to 4.1, I think I will work for those versions of PHP, for a few reasons, mostly the fact that the database configuration would work best on newer versions.
The configuration database system is a very advanced feature. Those that are running it will most likely be very high end users or ISPs. That means they will be running up to date versions of PHP and MySQL. If they aren't, then they should be running them.
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.
I agree, it's a "very poor substituate" BUT I can't imagine an other way to do it. We already have widely debated about the "SHOW GRANTS" limits in one hand, we can't rely neither on the "SHOW DATABASE" query neither on the "mysql_db_list" function on the other hand (since lots of shared server disable this features for security and server charge reasons). That's a real and annoying problem...
I was off the mailing list for a while. Could somebody recap as to why SHOW GRANTS and SHOW DATABASE are not workable? Is there any reason other than the version of MySQL?
How many ISPs still use MySQL 3.22? Additionally, looking thru the MySQL mailing list, it is possible that 3.22 will reach the end of it's support life when 4.0 is fully rolled out.
-
Lo�c -
Robin Johnson