[Dev] Multiple database support

[Michael Nels]

Great stuff, Brett.  Thanks.


On 5/21/08 9:53 AM, "Brett Wooldridge" <bwooldridge at alterpoint.com> wrote:

Team,

In 2008.04b we will finally be able to support databases other than the embedded Derby.  I've finally worked the kinks out of MySQL/Bitronix, which was the last hold-out.

As good as Derby is, there are those who have preferred or even required databases (in a corporate environment) that are different.  But I'm going to try very hard to avoid an explosion of supported databases.  In fact, if we never add another one I'll be happy.  I'd prefer NOT to support Microsoft SQL Server and Oracle.  First and foremost, I can't easily run either in my environment and since I'm the one holding up the database support, those two databases are not supported.  There is a cost, and not a small one, to supporting a new database.  Every schema change or addition must be duplicated and tested.  Migrations, particularly data migrations are very costly to implement and test.  If a company is willing to run ZipTie (an open source product), they can almost certainly run MySQL.  They may prefer something else, but I'm betting they'll suck it up.  Don't like it?  Don't run ZipTie.  Or join the team and offer to add (and support!) your preferred database.

Which brings me to the meat of this email.  There is a new utility called 'dbutil' (actually 'dbutil.pl') that ships with ZipTie.  This utility can be used to reset (i.e. create or re-create) the database.  The 'dbutil' utility is also now used by the 'dbreset' target in the build - you will notice no change in behavior.  However, it is about 2 seconds slower for MySQL and PostgreSQL, and about 4 seconds slower for Derby due to "shelling out".

You can also run the utility from the Build project, but the 'dbreset' Ant target is more convenient because it supplies all of the command arguments necessary.  However, if for example you are running against a remote MySQL, you will have to use the command-line utility.  But note this wasn't even possible before.  If running remotely, there is still a file to be tweaked in the installation.  If someone wants to get very clever they can change dbutil to go tweak the file.

Under Linux or OS X you can run the utility like any script (./dbutil.pl), on Windows you have to invoke 'perl' directly (i.e. perl dbutil.pl).  Doing so without arguments will yield this:

./dbutil.pl
Usage: dbutil [options] <action>

Options:
  --db   database (one of: derby, mysql, pgsql)
  --user the user to connect to the database as (optional)
  --pass the password to connect to the database with (optional)
  --host the hostname of the database server (optional)
  --port the port number of the database server (optional)
  --dir  the ZipTie installation directory (optional)

Actions:
   reset  reset ZipTie to it's original state

You can see that there is only one action at present (reset).  An invocation from 'dist' (or the installation directory) looks like this:

./dbutil.pl -db=mysql reset

If you are running 'dbutil' from Build you must specify the '--dir' option with a value of "../dist/server".  However, as mentioned, from Build just use the 'dbreset' Ant target.

So, we now have support for Derby, MySQL, and PostgreSQL.  If you have any questions or problems with the utility, database setup, or ZipTie issues on a given database let me know.

-Brett




Michael Nels | Sr. Director, Open Products

[cid:3294220598_1409803]

301 Congress Ave | Suite 400 | Austin, TX 78701
Office: 512.536.8313 | Fax:  512.651.3160

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20080521/ffaa44f7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.gif
Type: image/gif
Size: 3813 bytes
Desc: image.gif
Url : http://mailman.ziptie.org/pipermail/dev/attachments/20080521/ffaa44f7/attachment.gif