2
Mamba:
Is there a tracking system that shows who is working on what and what items are planned to be included? I know such systems exist because we used one in one of my programming classes. They also track where the person is on the "tasks". (Haven't started yet, % done on coding, level of code status (alpha, beta etc))
Wishcraft:
In reference to the Database stuff. No one "gave" me any sort of task. After the short debate over the ADODB - PDO debate nothing else seemed to be done. The way it seemed to me was that the database stuff was put on hold. I asked here and in the core mail lists if there was a need for someone to work on PDO stuff and didn't get any responses. I got no responses to related threads I posted as well. With the Database Optimization Challenge that was posted I thought it would be a good project to work on especially since the current MySQL PHP extension has been depreciated and will be likely removed from a future version of PHP which would cripple Xoops. I posted a converted class based on a Procedural version of the newer MySQLi extension which was created with a script after which I edited to make sure it still reflected what it should. This runs fine on my home system.
If you in fact have written a PDO class then I really don't need to waste time working on one. However after looking through your ADODB class stuff I have to wonder if you do a PDO class set if it is going to be as complex as what is in the SVN. Your ADODB design is complex and hard to trace which is bad for core code if it is to be included. As to performance numbers etc, really these are just database connection classes and should show no difference in performance and just be a difference in implementation and possibly code quality. The difference in performance will come when the core is refactored to take into account the improved security and performance gains available from the new features.
With relation to PDO I came across 2 things...
1. PDO makes use of interrupts for error trapping and these should be used any time you use a PDO function. If you fail to do so then the default error display will display the error connection including all of the connect string which includes the database name, user, and password information. It is important to make sure you have the interrupt error trapping turned on and always use try..catch blocks around ANY PDO related accesses.
2. PDO is an abstract class and as such has a code base that if you limit yourself to the most commonly supported features then the core and any modules written with it properly will work with any of the databases PDO supports. It does however also have support to allow different databases to make use of their strengths by having additional parameters and such that can be called. So different databases can have some specialized items that can be utilized. Since those specialized items however are limited to specific databases I don't believe they should be used (at least not in the core). We should try to generalize the code as much as we can to make it compatible across the board. And in relation to what the core has available now this should not be a big issue at this step. The main idea here is that the PDO extension was created with the intention of allowing any database to be used without having to make major changes to the code. In essence you should ONLY need to change the connect string to change databases and everything else should just work.
This does bring about an interesting concept as well. I discussed this briefly with Mamba when I visited him but I think we need to modify the whole Database class structure. This class was originally designed approximately 10 years ago before things like PDO or ADODB existed and the idea was to some day support multiple databases. Assuming PDO becomes the defacto standard extension the database class structure should be modified to streamline the use of this extension and thus allow the core programmers to make use of the new features it brings.
The most simple change would be to convert it to one class file. This is assuming the only change we need to make is mainly to the connect string. By using a switch statement for the database connect string we don't need the extra files under the current system. The rest of the class could then be simple PDO based code and not need additional files.
if however we need to support different code beyond just the connect string for different databases then we could keep the same structure but modify the database.php file to include all of the base PDO code. Then we just use small database specialized files that only includes the code that is different from the base code thus simplifying the supporting files.
