DBIx::Class::Tutorial::WhatIs - What is DBIx::Class and why would you use it?
It's an ORM (Object Relational Mapper) in Perl.
It writes SQL for you.
It supports/has been used with MySQL, SQLite, Postgres, Oracle, DB2, MS SQL Server.
It knows about relationships.
It knows about transactions.
It gets the data right when you need it.
It can create the database for you.
Classes can be imported from an existing database.
You can add your own data to its objects.
You can enhance or override just about any part of it's behaviour.
It obsoletes Apache::DBI and manages the database connection behind the scenes.
It has an active community on IRC and the mailing list, willing to listen to problems and suggestions.
There is a growing list of useful and reusable add-ons.
New developers are welcome and given svn repository space for their contributions.
=====
Databases are complicated, and worse, they don't all implement the same set of features from the SQL standard. They also have their own little features that don't appear in the standard at all. Much like browsers, working with cross-database code, or just getting used to one when you are used to another, is quite a pain.
DBIx::Class aims to give you a database interface in a language you understand (Perl, at least I hope you do), in a way that hides a lot of the individual idiosyncracies. If you're new to working with databases, then DBIC helps you get your code up and running without having to know too much. If you're a database old-hat then you can still use DBIC for standardised coding, and it'll even let you have access to the lower levels of DBI if you are so inclined.
[[ Should probably note at this point that DBIC does not cover every aspect of standard SQL yet (subsels, unions, joins without equality), we're working on it, and you can still wrangle them in]].
DBIx::Class' strengths lie in compiling a database query from any number of chained search attributes, and only running the actual query at the point where concrete data is required. A query representation (ResultSet) can be passed around, added to and changed. It can also be queried and re-queried, either afresh or using cached data from the initial query. A ResultSet can represent a query across any number of tables, provided they have defined relationships.
ResultSets are supported by result definition classes (result classes), describing the layout of your database, your column types, primary and other keys, indexes and most importantly, the relationships from one table to another. These classes are the perl representation of the database structure. You can create them by importing from a current physical database, or write them by hand. You can include relationships that do not exist as foreign references or constraints in your database.
The data returned from a ResultSet query is given in the form of perl objects, these will contain accessors to retrieve the actual data from the various columns of the query. In addiction, each object has accessors to retrieve any related data, as defined in the result classes. Data can be returned as raw strings/perl scalars, or, with the application of some bells and whistles, be returned as other Perl objects, for example a column containing a database-native date and time, can be returned as "2008-08-06 13:00:00.00000", or, more usefully, as a complete DateTime object. An IP could be returned as a Net::IP object, and so on.
=====
DBIx::Class supports and encourages a single design source. The distribution DBIx-Class-Schema-Loader can be used to extract information about existing database tables and create a DBIx::Class schema for you. If changes are made to the tables in the database, Loader can be used to rescan the tables. Using DBIx::Class::Schema::Loader is described in chapter X. Alternatively, your DBIx::Class files themselves can be the database layout design source. Databae tables can be created from the files, on all the supported databases. Changes to the column definitions in the files can be reflected in the database. This is described in chapter X.
Last modified: