Simon Elliott > DBIx-Class-0.06002 > DBIx::Class::ResultSet

Download:
DBIx-Class-0.06002.tar.gz

Dependencies

Annotate this POD (5)

CPAN RT

New  15
Open  16
Stalled  12
View/Report Bugs
Source   Latest Release: DBIx-Class-0.08270

NAME ^

DBIx::Class::ResultSet - Responsible for fetching and creating resultset.

SYNOPSIS ^

  my $rs   = $schema->resultset('User')->search(registered => 1);
  my @rows = $schema->resultset('CD')->search(year => 2005);

DESCRIPTION ^

The resultset is also known as an iterator. It is responsible for handling queries that may return an arbitrary number of rows, e.g. via "search" or a has_many relationship.

In the examples below, the following table classes are used:

  package MyApp::Schema::Artist;
  use base qw/DBIx::Class/;
  __PACKAGE__->load_components(qw/Core/);
  __PACKAGE__->table('artist');
  __PACKAGE__->add_columns(qw/artistid name/);
  __PACKAGE__->set_primary_key('artistid');
  __PACKAGE__->has_many(cds => 'MyApp::Schema::CD');
  1;

  package MyApp::Schema::CD;
  use base qw/DBIx::Class/;
  __PACKAGE__->load_components(qw/Core/);
  __PACKAGE__->table('cd');
  __PACKAGE__->add_columns(qw/cdid artist title year/);
  __PACKAGE__->set_primary_key('cdid');
  __PACKAGE__->belongs_to(artist => 'MyApp::Schema::Artist');
  1;

METHODS ^

new

Arguments: $source, \%$attrs
Return Value: $rs

The resultset constructor. Takes a source object (usually a DBIx::Class::ResultSourceProxy::Table) and an attribute hash (see "ATTRIBUTES" below). Does not perform any queries -- these are executed as needed by the other methods.

Generally you won't need to construct a resultset manually. You'll automatically get one from e.g. a "search" called in scalar context:

  my $rs = $schema->resultset('CD')->search({ title => '100th Window' });

IMPORTANT: If called on an object, proxies to new_result instead so

  my $cd = $schema->resultset('CD')->new({ title => 'Spoon' });

will return a CD object, not a ResultSet.

search

Arguments: $cond, \%attrs?
Return Value: $resultset (scalar context), @row_objs (list context)
  my @cds    = $cd_rs->search({ year => 2001 }); # "... WHERE year = 2001"
  my $new_rs = $cd_rs->search({ year => 2005 });

  my $new_rs = $cd_rs->search([ { year => 2005 }, { year => 2004 } ]);
                 # year = 2005 OR year = 2004

If you need to pass in additional attributes but no additional condition, call it as search(undef, \%attrs).

  # "SELECT name, artistid FROM $artist_table"
  my @all_artists = $schema->resultset('Artist')->search(undef, {
    columns => [qw/name artistid/],
  });

search_literal

Arguments: $sql_fragment, @bind_values
Return Value: $resultset (scalar context), @row_objs (list context)
  my @cds   = $cd_rs->search_literal('year = ? AND title = ?', qw/2001 Reload/);
  my $newrs = $artist_rs->search_literal('name = ?', 'Metallica');

Pass a literal chunk of SQL to be added to the conditional part of the resultset query.

find

Arguments: @values | \%cols, \%attrs?
Return Value: $row_object

Finds a row based on its primary key or unique constraint. For example:

  my $cd = $schema->resultset('CD')->find(5);

Also takes an optional key attribute, to search by a specific key or unique constraint. For example:

  my $cd = $schema->resultset('CD')->find(
    {
      artist => 'Massive Attack',
      title  => 'Mezzanine',
    },
    { key => 'artist_title' }
  );

See also "find_or_create" and "update_or_create".

search_related

Arguments: $cond, \%attrs?
Return Value: $new_resultset
  $new_rs = $cd_rs->search_related('artist', {
    name => 'Emo-R-Us',
  });

Searches the specified relationship, optionally specifying a condition and attributes for matching records. See "ATTRIBUTES" for more information.

cursor

Arguments: none
Return Value: $cursor

Returns a storage-driven cursor to the given resultset. See DBIx::Class::Cursor for more information.

single

Arguments: $cond?
Return Value: $row_object?
  my $cd = $schema->resultset('CD')->single({ year => 2001 });

Inflates the first result without creating a cursor if the resultset has any records in it; if not returns nothing. Used by find() as an optimisation.

search_like

Arguments: $cond, \%attrs?
Return Value: $resultset (scalar context), @row_objs (list context)
  # WHERE title LIKE '%blue%'
  $cd_rs = $rs->search_like({ title => '%blue%'});

Performs a search, but uses LIKE instead of = as the condition. Note that this is simply a convenience method. You most likely want to use "search" with specific operators.

For more information, see DBIx::Class::Manual::Cookbook.

slice

Arguments: $first, $last
Return Value: $resultset (scalar context), @row_objs (list context)

Returns a resultset or object list representing a subset of elements from the resultset slice is called on. Indexes are from 0, i.e., to get the first three records, call:

  my ($one, $two, $three) = $rs->slice(0, 2);

next

Arguments: none
Return Value: $result?

Returns the next element in the resultset (undef is there is none).

Can be used to efficiently iterate over records in the resultset:

  my $rs = $schema->resultset('CD')->search;
  while (my $cd = $rs->next) {
    print $cd->title;
  }

Note that you need to store the resultset object, and call next on it. Calling resultset('Table')->next repeatedly will always return the first record from the resultset.

result_source

Arguments: $result_source?
Return Value: $result_source

An accessor for the primary ResultSource object from which this ResultSet is derived.

count

Arguments: $cond, \%attrs??
Return Value: $count

Performs an SQL COUNT with the same query as the resultset was built with to find the number of elements. If passed arguments, does a search on the resultset and counts the results of that.

Note: When using count with group_by, DBIX::Class emulates GROUP BY using COUNT( DISTINCT( columns ) ). Some databases (notably SQLite) do not support DISTINCT with multiple columns. If you are using such a database, you should only use columns from the main table in your group_by clause.

count_literal

Arguments: $sql_fragment, @bind_values
Return Value: $count

Counts the results in a literal query. Equivalent to calling "search_literal" with the passed arguments, then "count".

all

Arguments: none
Return Value: @objects

Returns all elements in the resultset. Called implicitly if the resultset is returned in list context.

reset

Arguments: none
Return Value: $self

Resets the resultset's cursor, so you can iterate through the elements again.

first

Arguments: none
Return Value: $object?

Resets the resultset and returns an object for the first result (if the resultset returns anything).

update

Arguments: \%values
Return Value: $storage_rv

Sets the specified columns in the resultset to the supplied values in a single query. Return value will be true if the update succeeded or false if no records were updated; exact type of success value is storage-dependent.

update_all

Arguments: \%values
Return Value: 1

Fetches all objects and updates them one at a time. Note that update_all will run DBIC cascade triggers, while "update" will not.

delete

Arguments: none
Return Value: 1

Deletes the contents of the resultset from its result source. Note that this will not run DBIC cascade triggers. See "delete_all" if you need triggers to run.

delete_all

Arguments: none
Return Value: 1

Fetches all objects and deletes them one at a time. Note that delete_all will run DBIC cascade triggers, while "delete" will not.

pager

Arguments: none
Return Value: $pager

Return Value a Data::Page object for the current resultset. Only makes sense for queries with a page attribute.

page

Arguments: $page_number
Return Value: $rs

Returns a resultset for the $page_number page of the resultset on which page is called, where each page contains a number of rows equal to the 'rows' attribute set on the resultset (10 by default).

new_result

Arguments: \%vals
Return Value: $object

Creates an object in the resultset's result class and returns it.

create

Arguments: \%vals
Return Value: $object

Inserts a record into the resultset and returns the object representing it.

Effectively a shortcut for ->new_result(\%vals)->insert.

find_or_create

Arguments: \%vals, \%attrs?
Return Value: $object
  $class->find_or_create({ key => $val, ... });

Searches for a record matching the search condition; if it doesn't find one, creates one and returns that instead.

  my $cd = $schema->resultset('CD')->find_or_create({
    cdid   => 5,
    artist => 'Massive Attack',
    title  => 'Mezzanine',
    year   => 2005,
  });

Also takes an optional key attribute, to search by a specific key or unique constraint. For example:

  my $cd = $schema->resultset('CD')->find_or_create(
    {
      artist => 'Massive Attack',
      title  => 'Mezzanine',
    },
    { key => 'artist_title' }
  );

See also "find" and "update_or_create".

update_or_create

Arguments: \%col_values, { key => $unique_constraint }?
Return Value: $object
  $class->update_or_create({ col => $val, ... });

First, searches for an existing row matching one of the unique constraints (including the primary key) on the source of this resultset. If a row is found, updates it with the other given column values. Otherwise, creates a new row.

Takes an optional key attribute to search on a specific unique constraint. For example:

  # In your application
  my $cd = $schema->resultset('CD')->update_or_create(
    {
      artist => 'Massive Attack',
      title  => 'Mezzanine',
      year   => 1998,
    },
    { key => 'artist_title' }
  );

If no key is specified, it searches on all unique constraints defined on the source, including the primary key.

If the key is specified as primary, it searches only on the primary key.

See also "find" and "find_or_create".

get_cache

Arguments: none
Return Value: \@cache_objects?

Gets the contents of the cache for the resultset, if the cache is set.

set_cache

Arguments: \@cache_objects
Return Value: \@cache_objects

Sets the contents of the cache for the resultset. Expects an arrayref of objects of the same class as those produced by the resultset. Note that if the cache is set the resultset will return the cached objects rather than re-querying the database even if the cache attr is not set.

clear_cache

Arguments: none
Return Value: []

Clears the cache for the resultset.

related_resultset

Arguments: $relationship_name
Return Value: $resultset

Returns a related resultset for the supplied relationship name.

  $artist_rs = $schema->resultset('CD')->related_resultset('Artist');

throw_exception

See "throw_exception" in DBIx::Class::Schema for details.

ATTRIBUTES ^

The resultset takes various attributes that modify its behavior. Here's an overview of them:

order_by

Value: ($order_by | \@order_by)

Which column(s) to order the results by. This is currently passed through directly to SQL, so you can give e.g. year DESC for a descending order on the column `year'.

columns

Value: \@columns

Shortcut to request a particular set of columns to be retrieved. Adds me. onto the start of any column without a . in it and sets select from that, then auto-populates as from select as normal. (You may also use the cols attribute, as in earlier versions of DBIC.)

include_columns

Value: \@columns

Shortcut to include additional columns in the returned results - for example

  $schema->resultset('CD')->search(undef, {
    include_columns => ['artist.name'],
    join => ['artist']
  });

would return all CDs and include a 'name' column to the information passed to object inflation

select

Value: \@select_columns

Indicates which columns should be selected from the storage. You can use column names, or in the case of RDBMS back ends, function or stored procedure names:

  $rs = $schema->resultset('Employee')->search(undef, {
    select => [
      'name',
      { count => 'employeeid' },
      { sum => 'salary' }
    ]
  });

When you use function/stored procedure names and do not supply an as attribute, the column names returned are storage-dependent. E.g. MySQL would return a column named count(employeeid) in the above example.

as

Value: \@inflation_names

Indicates column names for object inflation. This is used in conjunction with select, usually when select contains one or more function or stored procedure names:

  $rs = $schema->resultset('Employee')->search(undef, {
    select => [
      'name',
      { count => 'employeeid' }
    ],
    as => ['name', 'employee_count'],
  });

  my $employee = $rs->first(); # get the first Employee

If the object against which the search is performed already has an accessor matching a column name specified in as, the value can be retrieved using the accessor as normal:

  my $name = $employee->name();

If on the other hand an accessor does not exist in the object, you need to use get_column instead:

  my $employee_count = $employee->get_column('employee_count');

You can create your own accessors if required - see DBIx::Class::Manual::Cookbook for details.

join

Value: ($rel_name | \@rel_names | \%rel_names)

Contains a list of relationships that should be joined for this query. For example:

  # Get CDs by Nine Inch Nails
  my $rs = $schema->resultset('CD')->search(
    { 'artist.name' => 'Nine Inch Nails' },
    { join => 'artist' }
  );

Can also contain a hash reference to refer to the other relation's relations. For example:

  package MyApp::Schema::Track;
  use base qw/DBIx::Class/;
  __PACKAGE__->table('track');
  __PACKAGE__->add_columns(qw/trackid cd position title/);
  __PACKAGE__->set_primary_key('trackid');
  __PACKAGE__->belongs_to(cd => 'MyApp::Schema::CD');
  1;

  # In your application
  my $rs = $schema->resultset('Artist')->search(
    { 'track.title' => 'Teardrop' },
    {
      join     => { cd => 'track' },
      order_by => 'artist.name',
    }
  );

If the same join is supplied twice, it will be aliased to <rel>_2 (and similarly for a third time). For e.g.

  my $rs = $schema->resultset('Artist')->search({
    'cds.title'   => 'Down to Earth',
    'cds_2.title' => 'Popular',
  }, {
    join => [ qw/cds cds/ ],
  });

will return a set of all artists that have both a cd with title 'Down to Earth' and a cd with title 'Popular'.

If you want to fetch related objects from other tables as well, see prefetch below.

prefetch

Value: ($rel_name | \@rel_names | \%rel_names)

Contains one or more relationships that should be fetched along with the main query (when they are accessed afterwards they will have already been "prefetched"). This is useful for when you know you will need the related objects, because it saves at least one query:

  my $rs = $schema->resultset('Tag')->search(
    undef,
    {
      prefetch => {
        cd => 'artist'
      }
    }
  );

The initial search results in SQL like the following:

  SELECT tag.*, cd.*, artist.* FROM tag
  JOIN cd ON tag.cd = cd.cdid
  JOIN artist ON cd.artist = artist.artistid

DBIx::Class has no need to go back to the database when we access the cd or artist relationships, which saves us two SQL statements in this case.

Simple prefetches will be joined automatically, so there is no need for a join attribute in the above search. If you're prefetching to depth (e.g. { cd => { artist => 'label' } or similar), you'll need to specify the join as well.

prefetch can be used with the following relationship types: belongs_to, has_one (or if you're using add_relationship, any relationship declared with an accessor type of 'single' or 'filter').

from

Value: \@from_clause

The from attribute gives you manual control over the FROM clause of SQL statements generated by DBIx::Class, allowing you to express custom JOIN clauses.

NOTE: Use this on your own risk. This allows you to shoot off your foot! join will usually do what you need and it is strongly recommended that you avoid using from unless you cannot achieve the desired result using join.

In simple terms, from works as follows:

    [
        { <alias> => <table>, -join_type => 'inner|left|right' }
        [] # nested JOIN (optional)
        { <table.column> => <foreign_table.foreign_key> }
    ]

    JOIN
        <alias> <table>
        [JOIN ...]
    ON <table.column> = <foreign_table.foreign_key>

An easy way to follow the examples below is to remember the following:

    Anything inside "[]" is a JOIN
    Anything inside "{}" is a condition for the enclosing JOIN

The following examples utilize a "person" table in a family tree application. In order to express parent->child relationships, this table is self-joined:

    # Person->belongs_to('father' => 'Person');
    # Person->belongs_to('mother' => 'Person');

from can be used to nest joins. Here we return all children with a father, then search against all mothers of those children:

  $rs = $schema->resultset('Person')->search(
      undef,
      {
          alias => 'mother', # alias columns in accordance with "from"
          from => [
              { mother => 'person' },
              [
                  [
                      { child => 'person' },
                      [
                          { father => 'person' },
                          { 'father.person_id' => 'child.father_id' }
                      ]
                  ],
                  { 'mother.person_id' => 'child.mother_id' }
              ],
          ]
      },
  );

  # Equivalent SQL:
  # SELECT mother.* FROM person mother
  # JOIN (
  #   person child
  #   JOIN person father
  #   ON ( father.person_id = child.father_id )
  # )
  # ON ( mother.person_id = child.mother_id )

The type of any join can be controlled manually. To search against only people with a father in the person table, we could explicitly use INNER JOIN:

    $rs = $schema->resultset('Person')->search(
        undef,
        {
            alias => 'child', # alias columns in accordance with "from"
            from => [
                { child => 'person' },
                [
                    { father => 'person', -join_type => 'inner' },
                    { 'father.id' => 'child.father_id' }
                ],
            ]
        },
    );

    # Equivalent SQL:
    # SELECT child.* FROM person child
    # INNER JOIN person father ON child.father_id = father.id

page

Value: $page

Makes the resultset paged and specifies the page to retrieve. Effectively identical to creating a non-pages resultset and then calling ->page($page) on it.

rows

Value: $rows

Specifes the maximum number of rows for direct retrieval or the number of rows per page if the page attribute or method is used.

group_by

Value: \@columns

A arrayref of columns to group by. Can include columns of joined tables.

  group_by => [qw/ column1 column2 ... /]

having

Value: $condition

HAVING is a select statement attribute that is applied between GROUP BY and ORDER BY. It is applied to the after the grouping calculations have been done.

  having => { 'count(employee)' => { '>=', 100 } }

distinct

Value: (0 | 1)

Set to 1 to group by all columns.

cache

Set to 1 to cache search results. This prevents extra SQL queries if you revisit rows in your ResultSet:

  my $resultset = $schema->resultset('Artist')->search( undef, { cache => 1 } );
  
  while( my $artist = $resultset->next ) {
    ... do stuff ...
  }

  $rs->first; # without cache, this would issue a query

By default, searches are not cached.

For more examples of using these attributes, see DBIx::Class::Manual::Cookbook.

syntax highlighting: