These examples assume that you already have a schema called MyApp::Schema::FilmDB, which defines some Result classes for tables in MyApp::Schema::FilmDB::Result::Actor and MyApp::Schema::FilmDB::Result::Film. Either created by the helper script (as shown above) or manually.

The helper also creates a Model in lib/MyApp/Model/FilmDB.pm, if you already have a schema you can create just the Model using:

The connect_info is optional and will be hardcoded into the Model if provided. It's better to configure it in your Catalyst config file, which will also override any hardcoded config, see "connect_info" for examples.

Now you have a working Model which accesses your separate DBIC Schema. This can be used/accessed in the normal Catalyst manner, via $c->model():

You can also define your own ResultSet methods to encapsulate the database/business logic of your applications. These go into, for example, lib/MyApp/Schema/FilmDB/ResultSet/Actor.pm. The class must inherit from DBIx::Class::ResultSet and is automatically loaded.

DESCRIPTION

When your Catalyst app starts up, a thin Model layer is created as an interface to your DBIC Schema. It should be clearly noted that the model object returned by $c->model('FilmDB') is NOT itself a DBIC schema or resultset object, but merely a wrapper proving methods to access the underlying schema.

In addition to this model class, a shortcut class is generated for each source in the schema, allowing easy and direct access to a resultset of the corresponding type. These generated classes are even thinner than the model class, providing no public methods but simply hooking into Catalyst's model() accessor via the ACCEPT_CONTEXT mechanism. The complete contents of each generated class is roughly equivalent to the following:

In order to add methods to a DBIC resultset, you cannot simply add them to the source (row, table) definition class; you must define a separate custom resultset class. This is just a matter of making a lib/MyApp/Schema/ResultSet/Actor.pm class that inherits from DBIx::Class::ResultSet, if you are using "load_namespaces" in DBIx::Class::Schema, the default for helper script generated schemas.

CONFIG PARAMETERS

schema_class

This is the classname of your DBIx::Class::Schema Schema. It needs to be findable in @INC, but it does not need to be inside the Catalyst::Model:: namespace. This parameter is required.

connect_info

This is a hashref or arrayref of connection parameters, which are specific to your storage_type (see your storage type documentation for more details). If you only need one parameter (e.g. the DSN), you can just pass a string.

This is not required if schema_class already has connection information defined inside itself (which isn't highly recommended, but can be done.)

For DBIx::Class::Storage::DBI, which is the only supported storage_type in DBIx::Class at the time of this writing, the parameters are your dsn, username, password, and connect options hashref.

traits

They are relative to the MyApp::TraitFor::Model::DBIC::Schema::, then the Catalyst::TraitFor::Model::DBIC::Schema:: namespaces, unless prefixed with + in which case they are taken to be a fully qualified name. E.g.:

traits Caching
traits +MyApp::TraitFor::Model::Foo

A new instance is created at application time, so any consumed required attributes, coercions and modifiers will work.

storage_type

Allows the use of a different storage_type than what is set in your schema_class (which in turn defaults to ::DBI if not set in current DBIx::Class). Completely optional, and probably unnecessary for most people until other storage backends become available for DBIx::Class.

ATTRIBUTES

The keys you pass in the model configuration are available as attributes.

METHODS

new

Instantiates the Model based on the above-documented ->config parameters. The only required parameter is schema_class. connect_info is required in the case that schema_class does not already have connection information defined for it.

schema

Accessor which returns the connected schema being used by the this model. There are direct shortcuts on the model class itself for schema->resultset, schema->source, and schema->class.

composed_schema

Accessor which returns the composed schema, which has no connection info, which was used in constructing the schema above. Useful for creating new connections based on the same schema/model. There are direct shortcuts from the model object for composed_schema->clone and composed_schema->connect