Okay, I warn you, this is hardly an easy task. If you're reading this, you would really like to run Mint(Mint Home Page) on something that is not MySQL. This is designed to walk you through getting Mint running on ADODB with the default Pepper. Fair warning though, this is not for the faint of heart, and this is certainly not for people who simply want a little Mint.
Some really really big disclaimers: No, I can't release the Mint code, I can only tell you what to look for and what to change. Shaun Inman put a lot of work into Mint, and it would be so incredibly wrong to post a hacked up Mint. It's also not fair to Mint. While we're rattling off disclaimers, I really encourage you to back up your Mint, make several copies of your data, and lightening proof your computer. I really can't be responsible for this working/not working. If this isn't working, please don't bug Shaun... he has his hands full with Mint in it's native form. Do this at your own risk!
Gotta Have Tools
Before starting this dangerous experiment, I recommend at least the following: * A good raw text editor * Lots of PHP knowledge helps (a ton) * A willingness to accept this might not work
Okay, now we also need to pick up your mint install (you know where to find it), and ADOdb for PHP (ADOdb Home Page) You will want to extract the adodb/ directory and place it in your Mint lib/ directory. We're now ready to hack and slash, starting with the Mint core class.
Mint()
The Mint class is in your lib/ directory in functions.php. The very first thing we need to do is add a line at the top of Mint (~ line 15):
include_once('adodb/adodb.inc.php');
This includes the adodb stuff. Now we are really ready to begin! Add a private variable for database type (var $database_type) and in the Mint constructor, set the database type to what you need ($this->database_type = 'mysql';). These settings are used later on when making SQL connections. Moving down, it's time to rewrite makeConnection(). Instead of using MySQL, we need to switch it to ADOdb. In order to provide a consistent way to get the connection, we are also going to use a static class variable for the connection.
The & before makeConnection means to return a reference to the connection (instead of a copy). This ensures we will always be using the same connection and not a clone of the connection. We also use ADOdb's PConnect to recreate Shaun's connection status. the commented line exists for enabling debug. I can't stress enough how important this line is. Uncomment it and keep trying until you get it working. Since it spits out every query it tries to run, all failures, and a really good backtrace, it will save you hours of headache. Next comes the _query() function. Unlike the current Mint, we are going to be calling Mint->query() from within our Pepper as well, so that there is a centralized point for running the queries. Like _makeConnection(), this too is a totally rewritten function.
The fetch mode is set to an associative array whenever possible. Your database will need to support field names in order for this to work, or it's back to numbered columns (which is not very pretty for the current Mint architecture). For most DBs though, this will work well. We then return the Result object from the ADOdb's Execute() method.
Since we are not planning to rewrite the update and insert statements for ADOdb, you will have to use a database that supports that sort of craziness. For the most part, Oracle does, and Postgres supports a good deal (excepting ALTER statements used in Pepper... more on that later). There may be further custom queries needed, but if that is the case, remember we can always pull down our database connection with $conn =& $this->_makeConnection(); or $conn => $this->Mint->_makeConnection(); inside a Pepper. From here though, things get much more dicey.
Mint() Find MySQL Instructions
There are several direct MySQL calls which need to be altered. Just do a search for mysql_query and you'll find them. Our format is going to change as follows (old on top, new on bottom):
So what did we do? Well, first, instead of handling the array directly, we have to perform the query. Since this is a select object, we must then catch the result and get the resulting data. Calling _query() now returns a Result object, which has 3 relevant items. Assuming $rs is our result, $rs->EOF is a flag which becomes true at the end of the recordset, $rs->fields is the current row (as an associative array), and $rs->MoveNext() moves the pointer and loads the new values for fields and EOF. This loop will be used in place of any iterations we find in Mint().
For UPDATE and INSERT, we won't need the Result, so we can simply call $this->_query(...) with the SQL statement.
The second kind of MySQL Instruction are actual MySQL statements in the SQL themselves. Key words to look for include OPTIMIZE TABLE, REPAIR TABLE, SHOW TABLE STATUS, etc. Using the debug flag will help here, as anything that doesn't work on your database version will throw up a big red flag. For all these functions, I simply checked if $this->database_type != 'mysql' and returned the "success" value, whatever it was supposed to be.
CREATE TABLE is an exception. Comment it out, make the table by hand, or be daring and change to ADOdb's create syntax. If you are using Postgres, the autonumber column will throw you for a loop, but if you are using Postgres, I'm pretty certain you've solved it before. It's only 2 tables, and a quick look at the code will tell you what columns you need.
The Default Pepper
See? Hasn't it been easy so far? You've only rewritten several queries into ADOdb format, and changed two functions. All told, the hardest part is finding what to change. $conn->debug = true is your friend! We're now ready for the class.php file in the Pepper directory. This is a ton of the same. Change mysql_query() to $this->Mint->_query(), use the new ADOdb loop, and you're pretty much done.
Additional Notes / Wrapping Up
This is more to get you started with ADOdb than anything else. I was able to get ADOdb running on MySQL and Oracle using these steps. However, you are going to make upgrading a nightmare if you go this route. If this sounds like a lot of work, getting MySQL with InnoDB on a machine with 4GB of memory / 3.0 GHz processor will do you a world of more good. But it is possible to get Mint running on alternate databases. It is just going to take a very substantial amount of work.
In response to "Chewing Gum: Sticking Mint to ADOdb":