X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FCookbook.pod;h=9b9f9cefc02abe669cf426272be50dd779ac9794;hb=47d7b769c034e04989840b1efc2f5991518cff23;hp=3c080046f92a0dfec85174d5084fd2b942adeaca;hpb=70e6d5f7d5881c08702f71c6de80effc2f264ade;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Manual/Cookbook.pod b/lib/DBIx/Class/Manual/Cookbook.pod index 3c08004..9b9f9ce 100644 --- a/lib/DBIx/Class/Manual/Cookbook.pod +++ b/lib/DBIx/Class/Manual/Cookbook.pod @@ -117,7 +117,12 @@ almost like you would define a regular ResultSource. __PACKAGE__->table_class('DBIx::Class::ResultSource::View'); - # ->table, ->add_columns, etc. + # For the time being this is necessary even for virtual views + __PACKAGE__->table($view_name); + + # + # ->add_columns, etc. + # # do not attempt to deploy() this view __PACKAGE__->result_source_instance->is_virtual(1); @@ -326,10 +331,10 @@ You can write subqueries relatively easily in DBIC. }); my $rs = $schema->resultset('CD')->search({ - artist_id => { 'IN' => $inside_rs->get_column('id')->as_query }, + artist_id => { -in => $inside_rs->get_column('id')->as_query }, }); -The usual operators ( =, !=, IN, NOT IN, etc.) are supported. +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: @@ -349,8 +354,8 @@ from, select, and +select attributes. my $rs = $cdrs->search({ year => { '=' => $cdrs->search( - { artist_id => { '=' => { -ident => 'me.artist_id' } } }, - { alias => 'inner' } + { artist_id => { -ident => 'me.artist_id' } }, + { alias => 'sub_query' } )->get_column('year')->max_rs->as_query, }, }); @@ -359,11 +364,11 @@ 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 artist_id = me.artist_id - ) + WHERE year = ( + SELECT MAX(sub_query.year) + FROM cd sub_query + WHERE artist_id = me.artist_id + ) =head2 Predefined searches @@ -413,44 +418,62 @@ 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. (Unless your RDBMS supports indexes on expressions - including return values of functions - and you create an index on the return value of the function in question.) However, -it can be accomplished with C when necessary. - -Your approach for doing so will depend on whether you have turned -quoting on via the C and C attributes. If you -explicitly defined C and C in your -C (see L) then -you are using quoting, otherwise not. - -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 }); +it can be accomplished with C when necessary by resorting to +literal SQL: -With quoting on, or for a more portable solution, use literal SQL values with -placeholders: - - $rs->search(\[ 'YEAR(date_of_birth) = ?', [ plain_value => 1979 ] ]); + $rs->search( + \[ 'YEAR(date_of_birth) = ?', 1979 ] + ); # Equivalent SQL: # SELECT * FROM employee WHERE YEAR(date_of_birth) = ? - $rs->search({ +To include the function as part of a larger search, use the '-and' keyword +to collect the search conditions: + + $rs->search({ -and => [ name => 'Bob', - -nest => \[ 'YEAR(date_of_birth) = ?', [ plain_value => 1979 ] ], - }); + \[ 'YEAR(date_of_birth) = ?', 1979 ] + ]}); # Equivalent SQL: # SELECT * FROM employee WHERE name = ? AND YEAR(date_of_birth) = ? -Note: the C string in the C<< [ plain_value => 1979 ] >> part -should be either the same as the name of the column (do this if the type of the -return value of the function is the same as the type of the column) or -otherwise it's essentially a dummy string currently (use C as a -habit). It is used by L to handle special column types. +Note: the syntax for specifying the bind value's datatype and value is +explained in L. See also L. +=head2 Software Limits + +When your RDBMS does not have a working SQL limit mechanism (e.g. Sybase ASE) +and L is either too slow or does +not work at all, you can try the +L +L attribute, which skips over records to simulate limits +in the Perl layer. + +For example: + + my $paged_rs = $rs->search({}, { + rows => 25, + page => 3, + order_by => [ 'me.last_name' ], + software_limit => 1, + }); + +You can set it as a default for your schema by placing the following in your +C: + + __PACKAGE__->default_resultset_attributes({ software_limit => 1 }); + +B If you are dealing with large resultsets and your L or +ODBC/ADO driver does not have proper cursor support (i.e. it loads the whole +resultset into memory) then this feature will be extremely slow and use huge +amounts of memory at best, and may cause your process to run out of memory and +cause instability on your server at worst, beware! + =head1 JOINS AND PREFETCHING =head2 Using joins and prefetch @@ -581,7 +604,7 @@ C: # 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' + # WHERE artist.name = 'Bob Marley' AND liner_notes.notes LIKE '%some text%' # ORDER BY artist.name =head2 Multi-step joins @@ -694,9 +717,9 @@ SQL statements: =head1 ROW-LEVEL OPERATIONS -=head2 Retrieving a row object's Schema +=head2 Retrieving a result object's Schema -It is possible to get a Schema object from a row object like so: +It is possible to get a Schema object from a result object like so: my $schema = $cd->result_source->schema; # use the schema as normal: @@ -941,7 +964,7 @@ B test.pl Alternatively you can use L that implements exactly the above functionality. -=head2 Skip row object creation for faster results +=head2 Skip result 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 @@ -1040,7 +1063,7 @@ See L for more documentation. =head2 Creating a result set from a set of rows -Sometimes you have a (set of) row objects that you want to put into a +Sometimes you have a (set of) result objects that you want to put into a resultset without the need to hit the DB again. You can do that by using the L method: @@ -1089,7 +1112,7 @@ If you want to get a filtered result set, you can just add add to $attr as follo __PACKAGE__->has_many('pages' => 'Page', 'book', { where => { scrap => 0 } } ); -=head2 Many-to-many relationships +=head2 Many-to-many relationship bridges This is straightforward using L: @@ -1334,9 +1357,9 @@ row. }); } catch { $exception = $_; - } + }; - if ($caught) { + if ($exception) { # There was an error while handling the $job. Rollback all changes # since the transaction started, including the already committed # ('released') savepoints. There will be neither a new $job nor any @@ -1381,14 +1404,21 @@ retry if the server goes away mid-operations, unlike C. L will connect to a database and create a L and associated sources by examining the database. -The recommend way of achieving this is to use the +The recommend way of achieving this is to use the L utility or the +L helper, as described in +L. + +Alternatively, use the L method: perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:./lib \ - -e 'make_schema_at("My::Schema", { debug => 1 }, [ "dbi:Pg:dbname=foo","postgres" ])' + -e 'make_schema_at("My::Schema", \ + { db_schema => 'myschema', components => ["InflateColumn::DateTime"] }, \ + [ "dbi:Pg:dbname=foo", "username", "password" ])' -This will create a tree of files rooted at C<./lib/My/Schema/> containing -source definitions for all the tables found in the C database. +This will create a tree of files rooted at C<./lib/My/Schema/> containing source +definitions for all the tables found in the C schema in the C +database. =head2 Creating DDL SQL @@ -1707,7 +1737,7 @@ methods: numbers => [1, 2, 3] }); - $row->update( + $result->update( { numbers => [1, 2, 3] }, @@ -1731,8 +1761,41 @@ See L and L for more explanation. Note that L sets L to C, so you must pass the bind values (the C<[1, 2, 3]> arrayref in the above example) wrapped in -arrayrefs together with the column name, like this: C<< [column_name => value] ->>. +arrayrefs together with the column name, like this: +C<< [column_name => value] >>. + +=head2 Formatting DateTime objects in queries + +To ensure C conditions containing L arguments are properly +formatted to be understood by your RDBMS, you must use the C +formatter returned by L to format +any L objects you pass to L +conditions. Any L object attached to your +L provides a correct C formatter, so +all you have to do is: + + my $dtf = $schema->storage->datetime_parser; + my $rs = $schema->resultset('users')->search( + { + signup_date => { + -between => [ + $dtf->format_datetime($dt_start), + $dtf->format_datetime($dt_end), + ], + } + }, + ); + +Without doing this the query will contain the simple stringification of the +C object, which almost never matches the RDBMS expectations. + +This kludge is necessary only for conditions passed to +L, whereas +L, +L, +L (but not L) are all +L-aware and will do the right thing when supplied +an inflated C object. =head2 Using Unicode @@ -1878,8 +1941,9 @@ just looking for this. For example, say that you have three columns, C, C, and C. You would like to make changes to C and have C be automagically set to the value of C squared. -You can accomplish this by wrapping the C accessor with -L: +You can accomplish this by wrapping the C accessor with the C +method modifier, available through either L, +L or L modules): around number => sub { my ($orig, $self) = (shift, shift); @@ -1889,10 +1953,10 @@ L: $self->squared( $value * $value ); } - $self->next::method(@_); - } + $self->$orig(@_); + }; -Note that the hard work is done by the call to C, which +Note that the hard work is done by the call to C<< $self->$orig >>, which redispatches your call to store_column in the superclass(es). Generally, if this is a calculation your database can easily do, try @@ -2099,8 +2163,8 @@ L. =item * Use L in void context to insert data -when you don't need the resulting L objects, if possible, but -see the caveats. +when you don't need the resulting L objects, +if possible, but see the caveats. When inserting many rows, for best results, populate a large number of rows at a time, but not so large that the table is locked for an unacceptably long time.