X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FManual%2FCookbook.pod;h=56b325095b0723b3b99590a59dd1058f84d43b10;hb=a14c7707e77a043858976ec702d3972780edbe6d;hp=014ff381b591edad8a1e896786e2665b3a97ce3e;hpb=5947e40961b9814264573afd70326d828a07853a;p=dbsrgits%2FDBIx-Class-Historic.git diff --git a/lib/DBIx/Class/Manual/Cookbook.pod b/lib/DBIx/Class/Manual/Cookbook.pod index 014ff38..56b3250 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); @@ -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 @@ -440,6 +445,35 @@ etc.), but this may change in the future. 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 @@ -683,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: @@ -930,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 @@ -1029,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: @@ -2128,8 +2162,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.