Dear DBI users, This is to announce yet another wrapper module on top of DBI, just posted on CPAN. Please have a look and see whether it can help suit your needs. The discussion forum is on http://www.cpanforum.com/.
Below is an excerpt from the doc : DBIx::DataModel is written compactly as one single module, and only depends on DBI and the SQL::Abstract manpage. It is intended to help client applications in performing common tasks such as data conversion and associations between tables, while retaining an open access both to the base DBI layer and to the basic Perl datastructures, whenever lower-level operations are needed. The focus is on building trees of data which can then be passed to external helper modules for generating XML, Perl dumps, javascript JSON, templates of the Template Toolkit, etc. Such modules need to walk on the data tree, so they cannot work if everything is implemented as OO methods to be called on demand (because there is no simple way to ask for all available methods, and even if you get there, it is not possible to distinguish which of those methods encapsulate relevant data). Therefore DBIx::DataModel does not insist on OO information hiding; on the contrary, direct access to the object hash is encouraged for inspecting the data. In the same spirit, transaction handling is left to the client code. DBIx::DataModel defines an API for accessing the database from Perl, but will not create the database itself. So use your best database administration tools to define your schemas, tables, keys, relationships and integrity rules; then tell the bare minimum to DBIx::DataModel so that Perl programs can work with the data. To do so, you first declare your tables with their primary keys. Then you declare UML binary associations, which will give you a couple of methods to walk through the data, possibly with some additional WHERE filters. From your associations, you can also generate some Views to directly query a list of tables, with the appropriate joins between them. At each method call, it is possible to specify which subset of columns should be retrieved (or to rely on the default, namely '*'). Columns may have some associated handlers for performing data transformation of validation. You may also define column types in your schema so that every column of a given type inherits the same collection of handlers (think for example of a 'date' type or a 'phoneNumber' type).
