X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FCookbook.pod;h=fae1e9461eb25e4dbcbfeb153762f770cc8f848f;hb=336256bc90f8b0493251c4fd7d88c3cdf02f636c;hp=70e645cac577fd4e8277dee95d55634fceba135a;hpb=e60dc79fcd4d6318e83584b826526e65048b86a9;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Manual/Cookbook.pod b/lib/DBIx/Class/Manual/Cookbook.pod index 70e645c..fae1e94 100644 --- a/lib/DBIx/Class/Manual/Cookbook.pod +++ b/lib/DBIx/Class/Manual/Cookbook.pod @@ -2,14 +2,12 @@ DBIx::Class::Manual::Cookbook - Miscellaneous recipes -=head1 RECIPES +=head1 SEARCHING -=head2 Searching - -=head3 Paged results +=head2 Paged results When you expect a large number of results, you can ask L for a -paged resultset, which will fetch only a small number of records at a time: +paged resultset, which will fetch only a defined number of records at a time: my $rs = $schema->resultset('Artist')->search( undef, @@ -21,23 +19,12 @@ paged resultset, which will fetch only a small number of records at a time: return $rs->all(); # all records for page 1 -The C attribute does not have to be specified in your search: - - my $rs = $schema->resultset('Artist')->search( - undef, - { - rows => 10, - } - ); - - return $rs->page(1); # DBIx::Class::ResultSet containing first 10 records - -In either of the above cases, you can return a L object for the -resultset (suitable for use in e.g. a template) using the C method: +You can get a L object for the resultset (suitable for use +in e.g. a template) using the C method: return $rs->pager(); -=head3 Complex WHERE clauses +=head2 Complex WHERE clauses Sometimes you need to formulate a query using specific operators: @@ -70,7 +57,42 @@ This results in the following C clause: For more information on generating complex queries, see L. -=head3 Arbitrary SQL through a custom ResultSource +=head2 Retrieve one and only one row from a resultset + +Sometimes you need only the first "top" row of a resultset. While this can be +easily done with L<< $rs->first|DBIx::Class::ResultSet/first >>, it is suboptimal, +as a full blown cursor for the resultset will be created and then immediately +destroyed after fetching the first row object. +L<< $rs->single|DBIx::Class::ResultSet/single >> is +designed specifically for this case - it will grab the first returned result +without even instantiating a cursor. + +Before replacing all your calls to C with C please observe the +following CAVEATS: + +=over + +=item * +While single() takes a search condition just like search() does, it does +_not_ accept search attributes. However one can always chain a single() to +a search(): + + my $top_cd = $cd_rs -> search({}, { order_by => 'rating' }) -> single; + + +=item * +Since single() is the engine behind find(), it is designed to fetch a +single row per database query. Thus a warning will be issued when the +underlying SELECT returns more than one row. Sometimes however this usage +is valid: i.e. we have an arbitrary number of cd's but only one of them is +at the top of the charts at any given time. If you know what you are doing, +you can silence the warning by explicitly limiting the resultset size: + + my $top_cd = $cd_rs -> search ({}, { order_by => 'rating', rows => 1 }) -> single; + +=back + +=head2 Arbitrary SQL through a custom ResultSource Sometimes you have to run arbitrary SQL because your query is too complex (e.g. it contains Unions, Sub-Selects, Stored Procedures, etc.) or has to @@ -108,7 +130,7 @@ you have to add to your User class: SQL # Finally, register your new ResultSource with your Schema - My::Schema->register_source( 'UserFriendsComplex' => $new_source ); + My::Schema->register_extra_source( 'UserFriendsComplex' => $new_source ); Next, you can execute your complex query using bind parameters like this: @@ -118,9 +140,38 @@ Next, you can execute your complex query using bind parameters like this: } ) ]; -... and you'll get back a perfect L. +... and you'll get back a perfect L (except, of course, +that you cannot modify the rows it contains, ie. cannot call L, +L, ... on it). + +If you prefer to have the definitions of these custom ResultSources in separate +files (instead of stuffing all of them into the same resultset class), you can +achieve the same with subclassing the resultset class and defining the +ResultSource there: + + package My::Schema::UserFriendsComplex; + + use My::Schema::User; + use base qw/My::Schema::User/; + + __PACKAGE__->table('dummy'); # currently must be called before anything else -=head3 Using specific columns + # Hand in your query as a scalar reference + # It will be added as a sub-select after FROM, + # so pay attention to the surrounding brackets! + __PACKAGE__->name( \< to specify which ones you need. This is useful to avoid @@ -140,7 +191,7 @@ use anyway: This is a shortcut for C and C. -=head3 Using database functions or stored procedures +=head2 Using database functions or stored procedures The combination of C to @@ -184,7 +235,7 @@ any of your aliases using either of these: # Or use DBIx::Class::AccessorGroup: __PACKAGE__->mk_group_accessors('column' => 'name_length'); -=head3 SELECT DISTINCT with multiple columns +=head2 SELECT DISTINCT with multiple columns my $rs = $schema->resultset('Foo')->search( {}, @@ -196,9 +247,7 @@ any of your aliases using either of these: } ); - my $count = $rs->next->get_column('count'); - -=head3 SELECT COUNT(DISTINCT colname) +=head2 SELECT COUNT(DISTINCT colname) my $rs = $schema->resultset('Foo')->search( {}, @@ -210,7 +259,9 @@ any of your aliases using either of these: } ); -=head3 Grouping results + my $count = $rs->next->get_column('count'); + +=head2 Grouping results L supports C as follows: @@ -218,22 +269,74 @@ L supports C as follows: {}, { join => [qw/ cds /], - select => [ 'name', { count => 'cds.cdid' } ], + select => [ 'name', { count => 'cds.id' } ], as => [qw/ name cd_count /], group_by => [qw/ name /] } ); # Equivalent SQL: - # SELECT name, COUNT( cds.cdid ) FROM artist me - # LEFT JOIN cd cds ON ( cds.artist = me.artistid ) + # SELECT name, COUNT( cd.id ) FROM artist + # LEFT JOIN cd ON artist.id = cd.artist # GROUP BY name Please see L documentation if you are in any way unsure about the use of the attributes above (C< join >, C< select >, C< as > and C< group_by >). -=head3 Predefined searches +=head2 Subqueries (EXPERIMENTAL) + +You can write subqueries relatively easily in DBIC. + + my $inside_rs = $schema->resultset('Artist')->search({ + name => [ 'Billy Joel', 'Brittany Spears' ], + }); + + my $rs = $schema->resultset('CD')->search({ + artist_id => { 'IN' => $inside_rs->get_column('id')->as_query }, + }); + +The usual operators ( =, !=, IN, NOT IN, etc) are supported. + +B: You have to explicitly use '=' when doing an equality comparison. +The following will B work: + + my $rs = $schema->resultset('CD')->search({ + artist_id => $inside_rs->get_column('id')->as_query, + }); + +=head3 Support + +Subqueries are supported in the where clause (first hashref), and in the +from, select, and +select attributes. + +=head3 Correlated subqueries + + my $cdrs = $schema->resultset('CD'); + my $rs = $cdrs->search({ + year => { + '=' => $cdrs->search( + { artistid => { '=' => \'me.artistid' } }, + { alias => 'inner' } + )->get_column('year')->max_rs->as_query, + }, + }); + +That creates the following SQL: + + SELECT me.cdid, me.artist, me.title, me.year, me.genreid, me.single_track + FROM cd me + WHERE year = ( + SELECT MAX(inner.year) + FROM cd inner + WHERE artistid = me.artistid + ) + +=head3 EXPERIMENTAL + +Please note that subqueries are considered an experimental feature. + +=head2 Predefined searches You can write your own L class by inheriting from it and define often used searches as methods: @@ -257,12 +360,52 @@ and define often used searches as methods: To use your resultset, first tell DBIx::Class to create an instance of it for you, in your My::DBIC::Schema::CD class: + # class definition as normal + __PACKAGE__->load_components(qw/ Core /); + __PACKAGE__->table('cd'); + + # tell DBIC to use the custom ResultSet class __PACKAGE__->resultset_class('My::DBIC::ResultSet::CD'); +Note that C must be called after C and C, or you will get errors about missing methods. + Then call your new method in your code: my $ordered_cds = $schema->resultset('CD')->search_cds_ordered(); +=head2 Using SQL functions on the left hand side of a comparison + +Using SQL functions on the left hand side of a comparison is generally +not a good idea since it requires a scan of the entire table. However, +it can be accomplished with C when necessary. + +If you do not have quoting on, simply include the function in your search +specification as you would any column: + + $rs->search({ 'YEAR(date_of_birth)' => 1979 }); + +With quoting on, or for a more portable solution, use the C +attribute: + + $rs->search({}, { where => \'YEAR(date_of_birth) = 1979' }); + +=begin hidden + +(When the bind args ordering bug is fixed, this technique will be better +and can replace the one above.) + +With quoting on, or for a more portable solution, use the C and +C attributes: + + $rs->search({}, { + where => \'YEAR(date_of_birth) = ?', + bind => [ 1979 ] + }); + +=end hidden + +=head1 JOINS AND PREFETCHING + =head2 Using joins and prefetch You can use the C attribute to allow searching on, or sorting your @@ -274,7 +417,7 @@ a particular artist name: 'artist.name' => 'Bob Marley' }, { - join => [qw/artist/], # join the artist table + join => 'artist', # join the artist table } ); @@ -291,10 +434,10 @@ it in your C attribute: 'artist.name' => 'Bob Marley' }, { - join => [qw/ artist /], + join => 'artist', order_by => [qw/ artist.name /] } - }; + ); # Equivalent SQL: # SELECT cd.* FROM cd @@ -332,9 +475,9 @@ This allows you to fetch results from related tables in advance: 'artist.name' => 'Bob Marley' }, { - join => [qw/ artist /], + join => 'artist', order_by => [qw/ artist.name /], - prefetch => [qw/ artist /] # return artist data too! + prefetch => 'artist' # return artist data too! } ); @@ -361,7 +504,35 @@ Also note that C should only be used when you know you will definitely use data from a related table. Pre-fetching related tables when you only need columns from the main table will make performance worse! -=head3 Multi-step joins +=head2 Multiple joins + +In the examples above, the C attribute was a scalar. If you +pass an array reference instead, you can join to multiple tables. In +this example, we want to limit the search further, using +C: + + # Relationships defined elsewhere: + # CD->belongs_to('artist' => 'Artist'); + # CD->has_one('liner_notes' => 'LinerNotes', 'cd'); + my $rs = $schema->resultset('CD')->search( + { + 'artist.name' => 'Bob Marley' + 'liner_notes.notes' => { 'like', '%some text%' }, + }, + { + join => [qw/ artist liner_notes /], + order_by => [qw/ artist.name /], + } + ); + + # Equivalent SQL: + # SELECT cd.*, artist.*, liner_notes.* FROM cd + # JOIN artist ON cd.artist = artist.id + # JOIN liner_notes ON cd.id = liner_notes.cd + # WHERE artist.name = 'Bob Marley' + # ORDER BY artist.name + +=head2 Multi-step joins Sometimes you want to join more than one relationship deep. In this example, we want to find all C objects who have Cs whose C @@ -384,8 +555,8 @@ contain a specific string: # Equivalent SQL: # SELECT artist.* FROM artist - # JOIN ( cd ON artist.id = cd.artist ) - # JOIN ( liner_notes ON cd.id = liner_notes.cd ) + # LEFT JOIN cd ON artist.id = cd.artist + # LEFT JOIN liner_notes ON cd.id = liner_notes.cd # WHERE liner_notes.notes LIKE '%some text%' Joins can be nested to an arbitrary level. So if we decide later that we @@ -411,12 +582,39 @@ notes: # Equivalent SQL: # SELECT artist.* FROM artist - # JOIN ( cd ON artist.id = cd.artist ) - # JOIN ( liner_notes ON cd.id = liner_notes.cd ) - # JOIN ( author ON author.id = liner_notes.author ) + # LEFT JOIN cd ON artist.id = cd.artist + # LEFT JOIN liner_notes ON cd.id = liner_notes.cd + # LEFT JOIN author ON author.id = liner_notes.author # WHERE liner_notes.notes LIKE '%some text%' # AND author.name = 'A. Writer' +=head2 Multi-step and multiple joins + +With various combinations of array and hash references, you can join +tables in any combination you desire. For example, to join Artist to +CD and Concert, and join CD to LinerNotes: + + # Relationships defined elsewhere: + # Artist->has_many('concerts' => 'Concert', 'artist'); + + my $rs = $schema->resultset('Artist')->search( + { }, + { + join => [ + { + cds => 'liner_notes' + }, + 'concerts' + ], + } + ); + + # Equivalent SQL: + # SELECT artist.* FROM artist + # LEFT JOIN cd ON artist.id = cd.artist + # LEFT JOIN liner_notes ON cd.id = liner_notes.cd + # LEFT JOIN concert ON artist.id = concert.artist + =head2 Multi-step prefetch From 0.04999_05 onwards, C can be nested more than one relationship @@ -433,8 +631,8 @@ deep using the same syntax as a multi-step join: # Equivalent SQL: # SELECT tag.*, cd.*, artist.* FROM tag - # JOIN cd ON tag.cd = cd.cdid - # JOIN artist ON cd.artist = artist.artistid + # JOIN cd ON tag.cd = cd.id + # JOIN artist ON cd.artist = artist.id Now accessing our C and C relationships does not need additional SQL statements: @@ -442,289 +640,627 @@ SQL statements: my $tag = $rs->first; print $tag->cd->artist->name; -=head2 Columns of data - -If you want to find the sum of a particular column there are several -ways, the obvious one is to use search: - - my $rs = $schema->resultset('Items')->search( - {}, - { - select => [ { sum => 'Cost' } ], - as => [ 'total_cost' ], # remember this 'as' is for DBIx::Class::ResultSet not SQL - } - ); - my $tc = $rs->first->get_column('total_cost'); - -Or, you can use the L, which gets -returned when you ask the C for a column using -C: - - my $cost = $schema->resultset('Items')->get_column('Cost'); - my $tc = $cost->sum; - -With this you can also do: - - my $minvalue = $cost->min; - my $maxvalue = $cost->max; - -Or just iterate through the values of this column only: - - while ( my $c = $cost->next ) { - print $c; - } - - foreach my $c ($cost->all) { - print $c; - } +=head1 ROW-LEVEL OPERATIONS -C only has a limited number of built-in functions, if -you need one that it doesn't have, then you can use the C method -instead: +=head2 Retrieving a row object's Schema - my $avg = $cost->func('AVERAGE'); +It is possible to get a Schema object from a row object like so: -This will cause the following SQL statement to be run: + my $schema = $cd->result_source->schema; + # use the schema as normal: + my $artist_rs = $schema->resultset('Artist'); - SELECT AVERAGE(Cost) FROM Items me +This can be useful when you don't want to pass around a Schema object to every +method. -Which will of course only work if your database supports this function. -See L for more documentation. +=head2 Getting the value of the primary key for the last database insert -=head2 Using relationships +AKA getting last_insert_id -=head3 Create a new row in a related table +If you are using PK::Auto (which is a core component as of 0.07), this is +straightforward: - my $book->create_related('author', { name => 'Fred'}); + my $foo = $rs->create(\%blah); + # do more stuff + my $id = $foo->id; # foo->my_primary_key_field will also work. -=head3 Search in a related table +If you are not using autoincrementing primary keys, this will probably +not work, but then you already know the value of the last primary key anyway. -Only searches for books named 'Titanic' by the author in $author. +=head2 Stringification - my $author->search_related('books', { name => 'Titanic' }); +Employ the standard stringification technique by using the C +module. -=head3 Delete data in a related table +To make an object stringify itself as a single column, use something +like this (replace C with the column/method of your choice): -Deletes only the book named Titanic by the author in $author. + use overload '""' => sub { shift->name}, fallback => 1; - my $author->delete_related('books', { name => 'Titanic' }); +For more complex stringification, you can use an anonymous subroutine: -=head3 Ordering a relationship result set + use overload '""' => sub { $_[0]->name . ", " . + $_[0]->address }, fallback => 1; -If you always want a relation to be ordered, you can specify this when you -create the relationship. +=head3 Stringification Example -To order C<< $book->pages >> by descending page_number. +Suppose we have two tables: C and C. The table +specifications are: - Book->has_many('pages' => 'Page', 'book', { order_by => \'page_number DESC'} ); + Product(id, Description, category) + Category(id, Description) +C is a foreign key into the Category table. +If you have a Product object C<$obj> and write something like -=head2 Transactions + print $obj->category -As of version 0.04001, there is improved transaction support in -L and L. Here is an -example of the recommended way to use it: +things will not work as expected. - my $genus = $schema->resultset('Genus')->find(12); +To obtain, for example, the category description, you should add this +method to the class defining the Category table: - my $coderef2 = sub { - $genus->extinct(1); - $genus->update; - }; + use overload "" => sub { + my $self = shift; - my $coderef1 = sub { - $genus->add_to_species({ name => 'troglodyte' }); - $genus->wings(2); - $genus->update; - $schema->txn_do($coderef2); # Can have a nested transaction - return $genus->species; - }; + return $self->Description; + }, fallback => 1; - my $rs; - eval { - $rs = $schema->txn_do($coderef1); - }; +=head2 Want to know if find_or_create found or created a row? - if ($@) { # Transaction failed - die "the sky is falling!" # - if ($@ =~ /Rollback failed/); # Rollback failed +Just use C instead, then check C: - deal_with_failed_transaction(); + my $obj = $rs->find_or_new({ blah => 'blarg' }); + unless ($obj->in_storage) { + $obj->insert; + # do whatever else you wanted if it was a new row } -Nested transactions will work as expected. That is, only the outermost -transaction will actually issue a commit to the $dbh, and a rollback -at any level of any transaction will cause the entire nested -transaction to fail. Support for savepoints and for true nested -transactions (for databases that support them) will hopefully be added -in the future. - -=head2 Many-to-many relationships - -This is straightforward using L: - - package My::DB; - # ... set up connection ... - - package My::User; - use base 'My::DB'; - __PACKAGE__->table('user'); - __PACKAGE__->add_columns(qw/id name/); - __PACKAGE__->set_primary_key('id'); - __PACKAGE__->has_many('user_address' => 'My::UserAddress', 'user'); - __PACKAGE__->many_to_many('addresses' => 'user_address', 'address'); +=head2 Dynamic Sub-classing DBIx::Class proxy classes - package My::UserAddress; - use base 'My::DB'; - __PACKAGE__->table('user_address'); - __PACKAGE__->add_columns(qw/user address/); - __PACKAGE__->set_primary_key(qw/user address/); - __PACKAGE__->belongs_to('user' => 'My::User'); - __PACKAGE__->belongs_to('address' => 'My::Address'); +AKA multi-class object inflation from one table + +L classes are proxy classes, therefore some different +techniques need to be employed for more than basic subclassing. In +this example we have a single user table that carries a boolean bit +for admin. We would like like to give the admin users +objects(L) the same methods as a regular user but +also special admin only methods. It doesn't make sense to create two +seperate proxy-class files for this. We would be copying all the user +methods into the Admin class. There is a cleaner way to accomplish +this. - package My::Address; - use base 'My::DB'; - __PACKAGE__->table('address'); - __PACKAGE__->add_columns(qw/id street town area_code country/); - __PACKAGE__->set_primary_key('id'); +Overriding the C method within the User proxy-class +gives us the effect we want. This method is called by +L when inflating a result from storage. So we +grab the object being returned, inspect the values we are looking for, +bless it if it's an admin object, and then return it. See the example +below: + +B + + package DB::Schema; + + use base qw/DBIx::Class::Schema/; + + __PACKAGE__->load_classes(qw/User/); + + +B + + package DB::Schema::User; + + use strict; + use warnings; + use base qw/DBIx::Class/; + + ### Defined what our admin class is for ensure_class_loaded + my $admin_class = __PACKAGE__ . '::Admin'; + + __PACKAGE__->load_components(qw/Core/); + + __PACKAGE__->table('users'); + + __PACKAGE__->add_columns(qw/user_id email password + firstname lastname active + admin/); + + __PACKAGE__->set_primary_key('user_id'); + + sub inflate_result { + my $self = shift; + my $ret = $self->next::method(@_); + if( $ret->admin ) {### If this is an admin rebless for extra functions + $self->ensure_class_loaded( $admin_class ); + bless $ret, $admin_class; + } + return $ret; + } + + sub hello { + print "I am a regular user.\n"; + return ; + } + + + package DB::Schema::User::Admin; + + use strict; + use warnings; + use base qw/DB::Schema::User/; + + sub hello + { + print "I am an admin.\n"; + return; + } + + sub do_admin_stuff + { + print "I am doing admin stuff\n"; + return ; + } + +B test.pl + + use warnings; + use strict; + use DB::Schema; + + my $user_data = { email => 'someguy@place.com', + password => 'pass1', + admin => 0 }; + + my $admin_data = { email => 'someadmin@adminplace.com', + password => 'pass2', + admin => 1 }; + + my $schema = DB::Schema->connection('dbi:Pg:dbname=test'); + + $schema->resultset('User')->create( $user_data ); + $schema->resultset('User')->create( $admin_data ); + + ### Now we search for them + my $user = $schema->resultset('User')->single( $user_data ); + my $admin = $schema->resultset('User')->single( $admin_data ); + + print ref $user, "\n"; + print ref $admin, "\n"; + + print $user->password , "\n"; # pass1 + print $admin->password , "\n";# pass2; inherited from User + print $user->hello , "\n";# I am a regular user. + print $admin->hello, "\n";# I am an admin. + + ### The statement below will NOT print + print "I can do admin stuff\n" if $user->can('do_admin_stuff'); + ### The statement below will print + print "I can do admin stuff\n" if $admin->can('do_admin_stuff'); + +=head2 Skip row object creation for faster results + +DBIx::Class is not built for speed, it's built for convenience and +ease of use, but sometimes you just need to get the data, and skip the +fancy objects. + +To do this simply use L. + + my $rs = $schema->resultset('CD'); + + $rs->result_class('DBIx::Class::ResultClass::HashRefInflator'); + + my $hash_ref = $rs->find(1); + +Wasn't that easy? + +=head2 Get raw data for blindingly fast results + +If the L solution +above is not fast enough for you, you can use a DBIx::Class to return values +exactly as they come out of the data base with none of the convenience methods +wrapped round them. + +This is used like so: + + my $cursor = $rs->cursor + while (my @vals = $cursor->next) { + # use $val[0..n] here + } + +You will need to map the array offsets to particular columns (you can +use the I +and C instead of C + + my $rs = $schema->resultset('Dual')->search(undef, + { select => [ 'sydate' ], + as => [ 'now' ] + }, + ); + +All you have to do now is be careful how you access your resultset, the below +will not work because there is no column called 'now' in the Dual table class + + while (my $dual = $rs->next) { + print $dual->now."\n"; + } + # Can't locate object method "now" via package "MyAppDB::Dual" at headshot.pl line 23. + +You could of course use 'dummy' in C instead of 'now', or C to +your Dual class for whatever you wanted to select from dual, but that's just +silly, instead use C + + while (my $dual = $rs->next) { + print $dual->get_column('now')."\n"; + } + +Or use C + + my $cursor = $rs->cursor; + while (my @vals = $cursor->next) { + print $vals[0]."\n"; + } -To create a DBIx::Class schema from an existing database: +In case you're going to use this "trick" together with L or +L a table called "dual" will be created in your +current schema. This would overlap "sys.dual" and you could not fetch "sysdate" or +"sequence.nextval" anymore from dual. To avoid this problem, just tell +L to not create table dual: + + my $sqlt_args = { + add_drop_table => 1, + parser_args => { sources => [ grep $_ ne 'Dual', schema->sources ] }, + }; + $schema->create_ddl_dir( [qw/Oracle/], undef, './sql', undef, $sqlt_args ); + +Or use L + + $rs->result_class('DBIx::Class::ResultClass::HashRefInflator'); + while ( my $dual = $rs->next ) { + print $dual->{now}."\n"; + } + +Here are some example C attribute of C to force ordering). +and each result class then uses this as a base:- -=head2 Want to know if find_or_create found or created a row? + use base qw/MyDBICbase/; -Just use C instead, then check C: +then the load_components is only performed once, which can result in a +considerable startup speedup for schemas with many classes. - my $obj = $rs->find_or_new({ blah => 'blarg' }); - unless ($obj->in_storage) { - $obj->insert; - # do whatever else you wanted if it was a new row - } +=head2 Explicitly List Schema Result Classes -=head3 Wrapping/overloading a column accessor +The schema class will normally contain -Problem: Say you have a table "Camera" and want to associate a description -with each camera. For most cameras, you'll be able to generate the description from -the other columns. However, in a few special cases you may want to associate a -custom description with a camera. + __PACKAGE__->load_classes(); -Solution: +to load the result classes. This will use L +to find and load the appropriate modules. Explicitly defining the +classes you wish to load will remove the overhead of +L and the related directory operations:- -In your database schema, define a description field in the "Camera" table that -can contain text and null values. + __PACKAGE__->load_classes(qw/ CD Artist Track /); -In DBIC, we'll overload the column accessor to provide a sane default if no -custom description is defined. The accessor will either return or generate the -description, depending on whether the field is null or not. +If you are instead using the L +syntax to load the appropriate classes there is not a direct alternative +avoiding L. -First, in your "Camera" schema class, define the description field as follows: +=head1 MEMORY USAGE - __PACKAGE__->add_columns(description => { accessor => '_description' }); +=head2 Cached statements -Next, we'll define the accessor-wrapper subroutine: +L normally caches all statements with L<< prepare_cached()|DBI/prepare_cached >>. +This is normally a good idea, but if too many statements are cached, the database may use too much +memory and may eventually run out and fail entirely. If you suspect this may be the case, you may want +to examine DBI's L<< CachedKids|DBI/CachedKidsCachedKids_(hash_ref) >> hash: - sub description { - my $self = shift; + # print all currently cached prepared statements + print for keys %{$schema->storage->dbh->{CachedKids}}; + # get a count of currently cached prepared statements + my $count = scalar keys %{$schema->storage->dbh->{CachedKids}}; - # If there is an update to the column, we'll let the original accessor - # deal with it. - return $self->_description(@_) if @_; +If it's appropriate, you can simply clear these statements, automatically deallocating them in the +database: - # Fetch the column value. - my $description = $self->_description; + my $kids = $schema->storage->dbh->{CachedKids}; + delete @{$kids}{keys %$kids} if scalar keys %$kids > 100; - # If there's something in the description field, then just return that. - return $description if defined $description && length $descripton; +But what you probably want is to expire unused statements and not those that are used frequently. +You can accomplish this with L or L: - # Otherwise, generate a description. - return $self->generate_description; - } + use Tie::Cache; + use DB::Main; + my $schema = DB::Main->connect($dbi_dsn, $user, $pass, { + on_connect_do => sub { tie %{shift->_dbh->{CachedKids}}, 'Tie::Cache', 100 }, + }); =cut