Re: Re[2]: [PEAR-DEV] Package proposal

Hi Maxim, I have a couple of objections both on the sense of such a package and on your implementation. 1. Imagine a situation when 2 clients on 2 different machines (so, 2 different phps) are making requests to one and the same database through this caching package. You will have 2 different caches - so 2 wrong "views" of the database, because the first client couldn't know what changes are made by the second one and vice versa. 2. Many of the hosting companies provide some database administration tool, such as phpMyAdmin for example. As you have to agree, you can't force phpMyAdmin to use your caching mechanism. Even if it's possible, it will create again one "general cache" for each user - the main purpose you mentioned for not using MySQL's native caching. 3. Some of the hosting companies provide also ssh access - so the user is free to use the mysql's shell tool. 4. When the user imports a db dump via: mysql < dump.sql, or with some other tool - the cache will stay untouched and inconsistent. 5. I can't believe that it will be faster to go through the cache file and search for the query each time, than just to use MySQL's native caching. I'm not a hosting company, but it sounds very strange for me to provide old MySQL (3.x) and new PHP (with PEAR and with that package included). I had no time to look at every piece of code, but I've found already some bug-potential things: - In processQuery($query) method you assume that the query begins with the SQL command - no spaces or comments. See http://dev.mysql.com/doc/mysql/en/Query_Cache_How.html for an example: "Before MySQL 5.0, a query that begins with a leading comment might be cached, but could not be fetched from the cache. This problem is fixed in MySQL 5.0." In the same check you have to include also TRUNCATE and DROP commands. - Maybe I'm wrong, but it seems that you invoke getTables() each time you create a new instance of the object, which executes mysql_list_tables(), which is of course sent to the server...so you actually have the network overhead before any cache check is possible. - In _tablesInQuery($query) method you are using strpos() to check if a table is in a query or not. Now imagine that you have aliases or functions or just strings with the name of the table - your check will return true, even when the table doesn't exist in the query. You have to use some regular expressions here to determine the tables involved, rather than retrieving all the tables once, and looking for these *strings* in the query. Anyway, I think the first few points I just mentioned in the beginning are very important - the inconsistency risk here is just too high and I strongly believe that database caching should be done on the database. Regards, Kouber Saparev