Moving Onward

Written on June 27, 2008 by Mike Gerwitz

I’ve decided to put the Datapack system on hold for the time being, even though it’s nearly complete. Because I’ve redesigned the database backend even further, it serves no immediate purpose. Right now it’s simply slowing the project down. Therefore, I’m getting back to work on the reconstruction.

I have been trying to think of the best way to implement a database backend. The problem is - how do we support multiple database server efficiently? Other systems simply convert the queries at runtime. For example, when a query is generated, it is generated in one format (such as MySQL). That query is then passed to the database layer where it is handles appropriately. If MySQL is the selected server, great - nothing needs to be done. The query is sent to the server as it is and we move on with our lives. However, if the administrator has chosen a different format - say, PostgreSQL or a flat-file database, the query may need to be altered or converted so that the server can understand it. So, it is converted at runtime before being sent to the server. This is an unnecessary waste of time and will slow down execution for other database servers.

So I figured, the query should be generated in the proper format to begin with. That way, no conversion is necessary. This will require more work from the developer’s perspective, but will be worth it performance-wise. So I thought about implementing the query functions in the database class itself. But this raised some problems - how would user-created modules add to that? PHP doesn’t support the dynamic addition of class methods without the use of an extension. And having MyCustomBB rely on an extension is a very bad idea.

So, the approach I decided on is $db->extension_name->query_function(). This introduces database extensions. Database modules handle communication with the server. Extensions add functionality to the module. So when a user-created module is loaded (non-db module), they can call a function that will enable and add the extension. If the extension does not support the server that the administrator has selected (which I’m sure many user-created modules will not), it will instead load a converter extension which will serve as a bridge between the database module and the user extension. It will then use the slower method of converting the query before sending it to the server. If no database modules support (know how) to convert between the two query types, the system will prevent the module from being loaded to prevent errors while users are browsing the site. (This, of course, means that the module that uses the extension will be prevented from loading.)

Posted in Planning