X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FIntro.pod;h=5414e0864b57de9b5c3d2374e90dea9a8af4f97b;hb=48580715af3072905f2c71dc27e7f70f21a11338;hp=10cb50e7836937fa1ac5f00a017caacd419a9e63;hpb=429bd4f15b0ea80aef96873a9db11801538eb3ee;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Manual/Intro.pod b/lib/DBIx/Class/Manual/Intro.pod index 10cb50e..5414e08 100644 --- a/lib/DBIx/Class/Manual/Intro.pod +++ b/lib/DBIx/Class/Manual/Intro.pod @@ -1,168 +1,414 @@ -=head1 Introduction. +=head1 NAME -So, you are bored with SQL, and want a native perl interface for your classes? -Or you've been doing this for a while with L, and think there's -a better way? You've come to the right place. Let's look at how you can set -and use your first native DBIx::Class tree. +DBIx::Class::Manual::Intro - Introduction to DBIx::Class -First we'll see how you can set up your classes yourself. If you want them -to be auto-discovered, just skip to the next section, which shows you how -to use DBIx::Class::Loader. +=head1 INTRODUCTION + +You're bored with SQL, and want a native Perl interface for your database? Or +you've been doing this for a while with L, and think there's a +better way? You've come to the right place. + +=head1 THE DBIx::Class WAY + +Here are a few simple tips that will help you get your bearings with +DBIx::Class. + +=head2 Tables become Result classes + +DBIx::Class needs to know what your Table structure looks like. You +do that by defining Result classes. Result classes are defined by +calling methods proxied to L. Each Result +class defines one Table, which defines the Columns it has, along with +any Relationships it has to other tables. (And oh, so much more +besides) The important thing to understand: + + A Result class == Table + +(most of the time, but just bear with my simplification) + +=head2 It's all about the ResultSet + +So, we've got some ResultSources defined. Now, we want to actually use those +definitions to help us translate the queries we need into handy perl objects! + +Let's say we defined a ResultSource for an "album" table with three columns: +"albumid", "artist", and "title". Any time we want to query this table, we'll +be creating a L from its ResultSource. For example, the +results of: + + SELECT albumid, artist, title FROM album; + +Would be retrieved by creating a ResultSet object from the album table's +ResultSource, likely by using the "search" method. + +DBIx::Class doesn't limit you to creating only simple ResultSets -- if you +wanted to do something like: + + SELECT title FROM album GROUP BY title; + +You could easily achieve it. + +The important thing to understand: + + Any time you would reach for a SQL query in DBI, you are + creating a DBIx::Class::ResultSet. + +=head2 Search is like "prepare" + +DBIx::Class tends to wait until it absolutely must fetch information from the +database. If you are returning a ResultSet, the query won't execute until you +use a method that wants to access the data. (Such as "next", or "first") + +The important thing to understand: + + Setting up a ResultSet does not execute the query; retrieving + the data does. + +=head2 Search results are returned as Rows + +Rows of the search from the database are blessed into +L objects. + +=head1 SETTING UP DBIx::Class + +Let's look at how you can set and use your first native L tree. + +First we'll see how you can set up your classes yourself. If you want them to +be auto-discovered, just skip to the next section, which shows you how to use +L. =head2 Setting it up manually -First, you'll need a base class. It should inherit from DBIx::Class -like this: +First, you should create your base schema class, which inherits from +L: + + package My::Schema; + use base qw/DBIx::Class::Schema/; + +In this class you load your result_source ("table", "model") classes, which we +will define later, using the load_namespaces() method: - package MyApp::DB - use base qw/DBIx::Class/; + # load My::Schema::Result::* and their resultset classes + __PACKAGE__->load_namespaces(); -You will also want to load some of L's components. -L provides a good basic set. In addition you'll -have to use either L or L We'll -use DB in this introduction, since it involves less magic. Schema is -mostly useful if you want to use multiple database connections. +By default this loads all the Result (Row) classes in the +My::Schema::Result:: namespace, and also any resultset classes in the +My::Schema::ResultSet:: namespace (if missing, the resultsets are +defaulted to be DBIx::Class::ResultSet objects). You can change the +result and resultset namespaces by using options to the +L call. - __PACKAGE__->load_components(qw/Core DB/); +It is also possible to do the same things manually by calling +C for the Row classes and defining in those classes any +required resultset classes. -If you want serial/auto-incremental primary keys, you'll need to add -the apropriate component for your db as well, for example +Next, create each of the classes you want to load as specified above: - __PACKAGE__->load_components(qw/Core DB PK::Auto::SQLite/); + package My::Schema::Result::Album; + use base qw/DBIx::Class::Core/; -Once you've loaded the components, it's time to set up your connection: +Load any additional components you may need with the load_components() method, +and provide component configuration if required. For example, if you want +automatic row ordering: - __PACKAGE__->connection('dbi:SQLite:/home/me/myapp/my.db'); + __PACKAGE__->load_components(qw/ Ordered /); + __PACKAGE__->position_column('rank'); -This method is similar to the normal L, and can take user/pass/dbi -attribute hash as well as the dsn. +Set the table for your class: -With that out of the way, we can define our first table class: + __PACKAGE__->table('album'); - package MyApp::DB::Frob +Add columns to your class: - use base qw/MyApp::DB/; + __PACKAGE__->add_columns(qw/ albumid artist title rank /); -Then we specify which table it uses, +Each column can also be set up with its own accessor, data_type and other pieces +of information that it may be useful to have -- just pass C a hash: - __PACKAGE__->table('frob'); + __PACKAGE__->add_columns(albumid => + { accessor => 'album', + data_type => 'integer', + size => 16, + is_nullable => 0, + is_auto_increment => 1, + default_value => '', + }, + artist => + { data_type => 'integer', + size => 16, + is_nullable => 0, + is_auto_increment => 0, + default_value => '', + }, + title => + { data_type => 'varchar', + size => 256, + is_nullable => 0, + is_auto_increment => 0, + default_value => '', + }, + rank => + { data_type => 'integer', + size => 16, + is_nullable => 0, + is_auto_increment => 0, + default_value => '', + } + ); -and specify which columns it has. +DBIx::Class doesn't directly use most of this data yet, but various related +modules such as L make use of it. Also it allows you to +create your database tables from your Schema, instead of the other way around. +See L for details. - __PACKAGE__->add_columns(qw/id foo bar/); +See L for more details of the possible column +attributes. -This will automatically create accessors for each of the columns, so that -you can read/update the values in rows you've retrieved. +Accessors are created for each column automatically, so My::Schema::Result::Album will +have albumid() (or album(), when using the accessor), artist() and title() +methods. -Also, you need to tell it which column is the primary key: +Define a primary key for your class: - __PACKAGE__->set_primary_key('id'); + __PACKAGE__->set_primary_key('albumid'); -If you have multiple primary keys, just pass a list instead. +If you have a multi-column primary key, just pass a list instead: -That's pretty much all you need for a basic setup. If you have more advanced -needs like using more than 1 database connections for the same class, see -L. + __PACKAGE__->set_primary_key( qw/ albumid artistid / ); -=head2 Using L. +Define this class' relationships with other classes using either C +to describe a column which contains an ID of another Table, or C to +make a predefined accessor for fetching objects that contain this Table's +foreign key: -This is an additional class, and not part of the DBIx::Class distribution. -Like L, it inspects your database, and automatically -creates classes for all the tables in your database. Here's a simple setup: + # in My::Schema::Result::Artist + __PACKAGE__->has_many('albums', 'My::Schema::Result::Album', 'artist'); - package MyApp::DB; - - use DBIx::Class::Loader; +See L for more information about the various types of +available relationships and how you can design your own. + +=head2 Using L + +This is an external module, and not part of the L distribution. +Like L, it inspects your database, and automatically creates +classes for all the tables in your database. Here's a simple setup: + + package My::Schema; + use base qw/DBIx::Class::Schema::Loader/; + + __PACKAGE__->loader_options( relationships => 1 ); - my $loader=DBIx::Class::Loader->new( - dsn => 'dbi:SQLite:/home/me/myapp/my.db', - namespace => 'MyApp::DB'); 1; -This should be equivalent to the manual in the section above. -L takes lots of other options. For more information, -consult the reference documentation. +The actual autoloading process will occur when you create a connected instance +of your schema below. + +See the L documentation for more information on its +many options. + +=head2 Connecting + +To connect to your Schema, you need to provide the connection details or a +database handle. + +=head3 Via connection details + +The arguments are the same as for L: -=head2 Basic Usage + my $schema = My::Schema->connect('dbi:SQLite:/home/me/myapp/my.db'); -Once you've defined the basic classes, you can start interacting with your -database. The simplest way to get a column is by primary key: +You can create as many different schema instances as you need. So if you have a +second database you want to access: - my $frob=MyApp::DB::Frob->find(14); + my $other_schema = My::Schema->connect( $dsn, $user, $password, $attrs ); -This will run a select with id=14 in the WHERE clause, and return an instance -of MyApp::DB::Frob that represents this row. Once you have that row, you can -access and update columns +Note that L does not cache connections for you. If you use +multiple connections, you need to do this manually. - my $val=$frob->bar; - $frob->bar(14); +To execute some SQL statements on every connect you can add them as an option in +a special fifth argument to connect: -or if you prefer, you can use the set_column/get_column accessors instead -of the autogenerated accessors based on your column names. + my $another_schema = My::Schema->connect( + $dsn, + $user, + $password, + $attrs, + { on_connect_do => \@on_connect_sql_statments } + ); -Just like with L, you do an 'update' to commit your changes -to the database: +See L for more information about +this and other special C-time options. - $frob->update; +=head3 Via a database handle -If needed, you can drop your local changes instead like this: +The supplied coderef is expected to return a single connected database handle +(e.g. a L C<$dbh>) - $frob->discard_changes if $frob->is_changed; + my $schema = My::Schema->connect ( + sub { Some::DBH::Factory->connect }, + \%extra_attrs, + ); -As you can see, is_changed allows you to check if there are local changes to +=head2 Basic usage + +Once you've defined the basic classes, either manually or using +L, you can start interacting with your database. + +To access your database using your $schema object, you can fetch a +L representing each of your tables by +calling the C method. + +The simplest way to get a record is by primary key: + + my $album = $schema->resultset('Album')->find(14); + +This will run a C