This patch adds the outline for loading database modules. The goal is to implement all the database functionality in modules with a wrapper in the core which calls the loaded modules based on which database is requested in the config files for various different things. So, for example, registrations could go to a MySQL Cluster database (using the MySQL driver directly without ODBC overhead) while all other core stuff goes to Postgres or Oracle directly, without using ODBC. At least, that is the eventual end-goal. This is just the beginning of the very long and arduous process to get there. This initial database module outline does not implement prepared statements yet. That will be added in the future.

Another goal for this modular approach, which works directly with the database libraries, is the implementation of connection pools, replication, and redundant queries. Thus, a definition of a particular database in the config file can list two or more IP addresses which all write requests should be replicated to and multiple IP addresses (which could be different from the write requests) for reading data. The readers could be configured for read scaling, as well as redundancy. So, for example, you could list three addresses for writing which are master database servers that replicate to 10 nodes each. Then, you could list 30 reader IP addresses with a maximum of 3 IP addresses used per query (one from each group of 10). When a read query is executed, it could be executed simultaneously on all three IPs and whichever returns a result first would be used.

This connection pooling, replication, and redundancy support will be implemented in the core logic. The underlying database calls will be provided by the modules that this interface is for.