Alzabo is a two-fold program. Its first function is as a data modelling tool. Through either a schema creation interface or a custom perl program, you can create a set of schema, table, column, etc. objects that represent your data model. Alzabo is also capable of reverse engineering an existing data model. Its second function is as a RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. To take it a step further, you could then aggregate a set of rows from different tables into a larger container object which could understand the logical relationship between these tables. The Alzabo::MethodMaker module can be very helpful. For more information please see perldoc Alzabo or the Alzabo homepage at http://alzabo.sourceforge.net/. The full documentation in HTML form is available at http://alzabo.sourceforge.net/docs/ Install information is in the INSTALL file. UPGRADING If you have an older version of Alzabo installed and you want to continue to use older schema objects you need to do the following steps _before_ installation. Run the convert.pl script in the eg/ directory. By default, it will attempt to convert all your schemas. This script generates files containing Perl code which will recreate your schema with the latest of version of Alzabo. Once you've run the convert.pl script for the all schemas you need to upgrade, install the latest version of Alzabo. Then run the files created by the convert.pl script. This overwrites your old files so _make backups first_! BUGS - Postgres, Perl 5.6.0+ and the 03-runtime.t test Running the 03-runtime.t test with Perl 5.6.0 (or 5.6.1 trial1) and Postgres produces a bunch of strange warning messages something like this: (in cleanup) dbih_getcom handle 'DBI::db=HASH(0x847d9c4)' is not a DBI handle (has no magic) at blib/lib/Alzabo/Driver.pm line 268 during global destruction. SV = RV(0x8474158) at 0x847d79c REFCNT = 1 FLAGS = (ROK) RV = 0x847d9c4 However, the tests still pass. I suspect this occurs because the 03-runtime test does a lot of forking and this may be doing strange things to the internal state of the DBI objects. If this also occurs during normal operations I will try to track it down but since I don't use 5.6.0 much, other than for compatibility testing, I may need some assistance. - Forking apps and Postgres In testing, I found that there were some problems using Postgres in a situation where you start the app, connect to the database, get some data, fork, reconnect, and and then get more data. I suspect that this has more to do with the DBD::Pg driver and/or Postgres itself than Alzabo. I don't believe this would be a problem with an app which forks before ever connecting to the database (such as mod_perl). I have structured the test suite to avoid this problem in testing but forewarned is forearmed (or something like that). CREDITS Thanks very much to Randal Schwartz for spending time with me on IRC helping me find problems with the install process. Bob Gustafson has provided extensive assistance in testing and debugging. Various bug reports and assistance from: Robin Berjon Rami Cohen-Scali Robert Goff Sam Horrocks Aaron Johnson