DBIx::Class::ResultSet - Represents a query used for fetching a set of results.

  my $users_rs   = $schema->resultset('User');
  my $registered_users_rs   = $schema->resultset('User')->search({ registered => 1 });
  my @cds_in_2005 = $schema->resultset('CD')->search({ year => 2005 })->all();

A ResultSet is an object which stores a set of conditions representing a query. It is the backbone of DBIx::Class (i.e. the really important/useful bit).

No SQL is executed on the database when a ResultSet is created, it just stores all the conditions needed to create the query.

A basic ResultSet representing the data of an entire table is returned by calling resultset on a DBIx::Class::Schema and passing in a Source (Source in DBIx::Class::Manual::Glossary) name.

  my $users_rs = $schema->resultset('User');

A new ResultSet is returned from calling search on an existing ResultSet. The new one will contain all the conditions of the original, plus any new conditions added in the search call.

A ResultSet also incorporates an implicit iterator. next and reset can be used to walk through all the DBIx::Class::Rows the ResultSet represents.

The query that the ResultSet represents is only executed against the database when these methods are called: find next all first single count

Let's say you've got a query that needs to be run to return some data to the user. But, you have an authorization system in place that prevents certain users from seeing certain information. So, you want to construct the basic query in one method, but add constraints to it in another.

  sub get_data {
    my $self = shift;
    my $request = $self->get_request; # Get a request object somehow.
    my $schema = $self->get_schema;   # Get the DBIC schema object somehow.

    my $cd_rs = $schema->resultset('CD')->search({
      title => $request->param('title'),
      year => $request->param('year'),
    });

    $self->apply_security_policy( $cd_rs );

    return $cd_rs->all();
  }

  sub apply_security_policy {
    my $self = shift;
    my ($rs) = @_;

    return $rs->search({
      subversive => 0,
    });
  }

When a resultset is chained from another resultset, conditions and attributes with the same keys need resolving.

join, prefetch, +select, +as attributes are merged into the existing ones from the original resultset.

The where, having attribute, and any search conditions are merged with an SQL AND to the existing condition from the original resultset.

All other attributes are overridden by any new ones supplied in the search attributes.

Since a resultset just defines a query, you can do all sorts of things with it with the same object.

  # Don't hit the DB yet.
  my $cd_rs = $schema->resultset('CD')->search({
    title => 'something',
    year => 2009,
  });

  # Each of these hits the DB individually.
  my $count = $cd_rs->count;
  my $most_recent = $cd_rs->get_column('date_released')->max();
  my @records = $cd_rs->all;

And it's not just limited to SELECT statements.

  $cd_rs->delete();

This is even cooler:

  $cd_rs->create({ artist => 'Fred' });

Which is the same as:

  $schema->resultset('CD')->create({
    title => 'something',
    year => 2009,
    artist => 'Fred'
  });

See: search, count, get_column, all, create.

If a resultset is used in a numeric context it returns the count. However, if it is used in a booleand context it is always true. So if you want to check if a resultset has any results use if $rs != 0. if $rs will always be true.

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.

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/],
  });

For a list of attributes that can be passed to search, see ATTRIBUTES. For more examples of using this function, see Searching (Searching in DBIx::Class::Manual::Cookbook). For a complete documentation for the first argument, see SQL::Abstract.

For more help on using joins with search, see DBIx::Class::Manual::Joining.

Arguments: $cond, \%attrs?

Return Value: $resultset

This method does the same exact thing as search() except it will always return a resultset, even in list context.

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.

CAVEAT: search_literal is provided for Class::DBI compatibility and should only be used in that context. search_literal is a convenience method. It is equivalent to calling $schema->search(\[]), but if you want to ensure columns are bound correctly, use search.

Example of how to use search instead of search_literal

  my @cds = $cd_rs->search_literal('cdid = ? AND (artist = ? OR artist = ?)', (2, 1, 2));
  my @cds = $cd_rs->search(\[ 'cdid = ? AND (artist = ? OR artist = ?)', [ 'cdid', 2 ], [ 'artist', 1 ], [ 'artist', 2 ] ]);

See Searching in DBIx::Class::Manual::Cookbook and Searching in DBIx::Class::Manual::FAQ for searching techniques that do not require search_literal.

Arguments: @values | \%cols, \%attrs?

Return Value: $row_object | undef

Finds a row based on its primary key or unique constraint. For example, to find a row by its primary key:

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

You can also find a row by a specific unique constraint using the key attribute. For example:

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

Additionally, you can specify the columns explicitly by name:

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

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

If no key is specified, it searches on all unique constraints defined on the source for which column data is provided, including the primary key.

If your table does not have a primary key, you must provide a value for the key attribute matching one of the unique constraints on the source.

In addition to key, find recognizes and applies standard resultset attributes in the same way as search does.

Note: If your query does not return only one row, a warning is generated:

  Query returned more than one row

See also find_or_create and update_or_create. For information on how to declare unique constraints, see add_unique_constraint in DBIx::Class::ResultSource.

Arguments: $rel, $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.

This method works exactly the same as search_related, except that it guarantees a restultset, even in list context.

Arguments: none

Return Value: $cursor

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

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 a lean version of search.

While this method can take an optional search condition (just like search) being a fast-code-path it does not recognize search attributes. If you need to add extra joins or similar, call search and then chain-call single on the DBIx::Class::ResultSet returned.

Note

As of 0.08100, this method enforces the assumption that the preceeding query returns only one row. If more than one row is returned, you will receive a warning:

  Query returned more than one row

In this case, you should be using next or find instead, or if you really know what you are doing, use the rows attribute to explicitly limit the size of the resultset.

This method will also throw an exception if it is called on a resultset prefetching has_many, as such a prefetch implies fetching multiple rows from the database in order to assemble the resulting object.

Arguments: $cond?

Return Value: $resultsetcolumn

  my $max_length = $rs->get_column('length')->max;

Returns a DBIx::Class::ResultSetColumn instance for a column of the ResultSet.

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 retained for ex Class::DBI users. You most likely want to use search with specific operators.

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

This method is deprecated and will be removed in 0.09. Use search() instead. An example conversion is:

  ->search_like({ foo => 'bar' });

  # Becomes

  ->search({ foo => { like => 'bar' } });

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);

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.

Arguments: $result_source?

Return Value: $result_source

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

Arguments: $result_class?

Return Value: $result_class

An accessor for the class to use when creating row objects. Defaults to result_source->result_class - which in most cases is the name of the "table" ("ResultSource" in DBIx::Class::Manual::Glossary) class.

Note that changing the result_class will also remove any components that were originally loaded in the source class via load_components in DBIx::Class::ResultSource. Any overloaded methods in the original source class will not run.

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. Passing arguments is equivalent to $rs->search ($cond, \%attrs)->count

Arguments: $cond, \%attrs??

Return Value: $count_rs

Same as count but returns a DBIx::Class::ResultSetColumn object. This can be very handy for subqueries:

  ->search( { amount => $some_rs->count_rs->as_query } )

As with regular resultsets the SQL query will be executed only after the resultset is accessed via next or all. That would return the same single value obtainable via count.

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.

Arguments: none

Return Value: @objects

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

Arguments: none

Return Value: $self

Resets the resultset's cursor, so you can iterate through the elements again. Implicitly resets the storage cursor, so a subsequent next will trigger another query.

Arguments: none

Return Value: $object?

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

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.

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.

Arguments: none

Return Value: $storage_rv

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. See also delete in DBIx::Class::Row.

Return value will be the amount of rows deleted; exact type of return value is storage-dependent.

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.

Arguments: \@data;

Accepts either an arrayref of hashrefs or alternatively an arrayref of arrayrefs. For the arrayref of hashrefs style each hashref should be a structure suitable forsubmitting to a $resultset->create(...) method.

In void context, insert_bulk in DBIx::Class::Storage::DBI is used to insert the data, as this is a faster method.

Otherwise, each set of data is inserted into the database using create in DBIx::Class::ResultSet, and the resulting objects are accumulated into an array. The array itself, or an array reference is returned depending on scalar or list context.

Example: Assuming an Artist Class that has many CDs Classes relating:

  my $Artist_rs = $schema->resultset("Artist");

  ## Void Context Example
  $Artist_rs->populate([
     { artistid => 4, name => 'Manufactured Crap', cds => [
        { title => 'My First CD', year => 2006 },
        { title => 'Yet More Tweeny-Pop crap', year => 2007 },
      ],
     },
     { artistid => 5, name => 'Angsty-Whiny Girl', cds => [
        { title => 'My parents sold me to a record company' ,year => 2005 },
        { title => 'Why Am I So Ugly?', year => 2006 },
        { title => 'I Got Surgery and am now Popular', year => 2007 }
      ],
     },
  ]);

  ## Array Context Example
  my ($ArtistOne, $ArtistTwo, $ArtistThree) = $Artist_rs->populate([
    { name => "Artist One"},
    { name => "Artist Two"},
    { name => "Artist Three", cds=> [
    { title => "First CD", year => 2007},
    { title => "Second CD", year => 2008},
  ]}
  ]);

  print $ArtistOne->name; ## response is 'Artist One'
  print $ArtistThree->cds->count ## reponse is '2'

For the arrayref of arrayrefs style, the first element should be a list of the fieldsnames to which the remaining elements are rows being inserted. For example:

  $Arstist_rs->populate([
    [qw/artistid name/],
    [100, 'A Formally Unknown Singer'],
    [101, 'A singer that jumped the shark two albums ago'],
    [102, 'An actually cool singer.'],
  ]);

Please note an important effect on your data when choosing between void and wantarray context. Since void context goes straight to insert_bulk in DBIx::Class::Storage::DBI this will skip any component that is overriding insert. So if you are using something like DBIx-Class-UUIDColumns to create primary keys for you, you will find that your PKs are empty. In this case you will have to use the wantarray context in order to create those values.

Private method used by populate to normalize its incoming arguments. Factored out in case you want to subclass and accept new argument structures to the populate method.

Arguments: none

Return Value: $pager

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

To get the full count of entries for a paged resultset, call total_entries on the Data::Page object.

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).

Arguments: \%vals

Return Value: $rowobject

Creates a new row object in the resultset's result class and returns it. The row is not inserted into the database at this point, call insert in DBIx::Class::Row to do that. Calling in_storage in DBIx::Class::Row will tell you whether the row object has been inserted or not.

Passes the hashref of input on to new in DBIx::Class::Row.

Arguments: none

Return Value: \[ $sql, @bind ]

Returns the SQL query and bind vars associated with the invocant.

This is generally used as the RHS for a subquery.

NOTE: This feature is still experimental.

Arguments: \%vals, \%attrs?

Return Value: $rowobject

  my $artist = $schema->resultset('Artist')->find_or_new(
    { artist => 'fred' }, { key => 'artists' });

  $cd->cd_to_producer->find_or_new({ producer => $producer },
                                   { key => 'primary });

Find an existing record from this resultset, based on its primary key, or a unique constraint. If none exists, instantiate a new result object and return it. The object will not be saved into your storage until you call insert in DBIx::Class::Row on it.

You most likely want this method when looking for existing rows using a unique constraint that is not the primary key, or looking for related rows.

If you want objects to be saved immediately, use find_or_create instead.

Note: Take care when using find_or_new with a table having columns with default values that you intend to be automatically supplied by the database (e.g. an auto_increment primary key column). In normal usage, the value of such columns should NOT be included at all in the call to find_or_new, even when set to undef.

Arguments: \%vals

Return Value: a DBIx::Class::Row $object

Attempt to create a single new row or a row with multiple related rows in the table represented by the resultset (and related tables). This will not check for duplicate rows before inserting, use find_or_create to do that.

To create one row for this resultset, pass a hashref of key/value pairs representing the columns of the table and the values you wish to store. If the appropriate relationships are set up, foreign key fields can also be passed an object representing the foreign row, and the value will be set to its primary key.

To create related objects, pass a hashref of related-object column values keyed on the relationship name. If the relationship is of type multi (has_many in DBIx::Class::Relationship) - pass an arrayref of hashrefs. The process will correctly identify columns holding foreign keys, and will transparrently populate them from the keys of the corresponding relation. This can be applied recursively, and will work correctly for a structure with an arbitrary depth and width, as long as the relationships actually exists and the correct column data has been supplied.

Instead of hashrefs of plain related data (key/value pairs), you may also pass new or inserted objects. New objects (not inserted yet, see new), will be inserted into their appropriate tables.

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

Example of creating a new row.

  $person_rs->create({
    name=>"Some Person",
    email=>"somebody@someplace.com"
  });

Example of creating a new row and also creating rows in a related has_many or has_one resultset. Note Arrayref.

  $artist_rs->create(
     { artistid => 4, name => 'Manufactured Crap', cds => [
        { title => 'My First CD', year => 2006 },
        { title => 'Yet More Tweeny-Pop crap', year => 2007 },
      ],
     },
  );

Example of creating a new row and also creating a row in a related belongs_toresultset. Note Hashref.

  $cd_rs->create({
    title=>"Music for Silly Walks",
    year=>2000,
    artist => {
      name=>"Silly Musician",
    }
  });

WARNING

When subclassing ResultSet never attempt to override this method. Since it is a simple shortcut for $self->new_result($attrs)->insert, a lot of the internals simply never call it, so your override will be bypassed more often than not. Override either new or insert depending on how early in the create process you need to intervene.

Arguments: \%vals, \%attrs?

Return Value: $rowobject

  $cd->cd_to_producer->find_or_create({ producer => $producer },
                                      { key => 'primary' });

Tries to find a record based on its primary key or unique constraints; if none is found, 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 => 'cd_artist_title' }
  );

Note: Because find_or_create() reads from the database and then possibly inserts based on the result, this method is subject to a race condition. Another process could create a record in the table after the find has completed and before the create has started. To avoid this problem, use find_or_create() inside a transaction.

Note: Take care when using find_or_create with a table having columns with default values that you intend to be automatically supplied by the database (e.g. an auto_increment primary key column). In normal usage, the value of such columns should NOT be included at all in the call to find_or_create, even when set to undef.

See also find and update_or_create. For information on how to declare unique constraints, see add_unique_constraint in DBIx::Class::ResultSource.

Arguments: \%col_values, { key => $unique_constraint }?

Return Value: $rowobject

  $resultset->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 => 'cd_artist_title' }
  );

  $cd->cd_to_producer->update_or_create({
    producer => $producer,
    name => 'harry',
  }, {
    key => 'primary,
  });

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. For information on how to declare unique constraints, see add_unique_constraint in DBIx::Class::ResultSource.

Note: Take care when using update_or_create with a table having columns with default values that you intend to be automatically supplied by the database (e.g. an auto_increment primary key column). In normal usage, the value of such columns should NOT be included at all in the call to update_or_create, even when set to undef.

Arguments: \%col_values, { key => $unique_constraint }?

Return Value: $rowobject

  $resultset->update_or_new({ 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, instantiate a new result object and return it. The object will not be saved into your storage until you call insert in DBIx::Class::Row on it.

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

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

  if ($cd->in_storage) {
      # the cd was updated
  }
  else {
      # the cd is not yet in the database, let's insert it
      $cd->insert;
  }

Note: Take care when using update_or_new with a table having columns with default values that you intend to be automatically supplied by the database (e.g. an auto_increment primary key column). In normal usage, the value of such columns should NOT be included at all in the call to update_or_new, even when set to undef.

See also find, find_or_create and find_or_new.

Arguments: none

Return Value: \@cache_objects?

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

The cache is populated either by using the prefetch attribute to search or by calling 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.

The contents of the cache can also be populated by using the prefetch attribute to search.

Arguments: none

Return Value: []

Clears the cache for the resultset.

Arguments: none

Return Value: true, if the resultset has been paginated

Arguments: $relationship_name

Return Value: $resultset

Returns a related resultset for the supplied relationship name.

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

Arguments: none

Return Value: $source_alias

Returns the current table alias for the result source this resultset is built on, that will be used in the SQL query. Usually it is me.

Currently the source alias that refers to the result set returned by a search/find family method depends on how you got to the resultset: it's me by default, but eg. search_related aliases it to the related result source name (and keeps me referring to the original result set). The long term goal is to make DBIx::Class always alias the current resultset as me (and make this method unnecessary).

Thus it's currently necessary to use this method in predefined queries (see Predefined searches in DBIx::Class::Manual::Cookbook) when referring to the source alias of the current result set:

  # in a result set class
  sub modified_by {
    my ($self, $user) = @_;

    my $me = $self->current_source_alias;

    return $self->search(
      "$me.modified" => $user->id,
    );
  }

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

Attributes are used to refine a ResultSet in various ways when searching for data. They can be passed to any method which takes an \%attrs argument. See search, search_rs, find, count.

These are in no particular order:

Value: ( $order_by | \@order_by | \%order_by )

Which column(s) to order the results by.

[The full list of suitable values is documented in "ORDER BY CLAUSES" in SQL::Abstract; the following is a summary of common options.]

If a single column name, or an arrayref of names is supplied, the argument is passed through directly to SQL. The hashref syntax allows for connection-agnostic specification of ordering direction:

 For descending order:

  order_by => { -desc => [qw/col1 col2 col3/] }

 For explicit ascending order:

  order_by => { -asc => 'col' }

The old scalarref syntax (i.e. order_by => \'year DESC') is still supported, although you are strongly encouraged to use the hashref syntax as outlined above.

Value: \@columns

Shortcut to request a particular set of columns to be retrieved. Each column spec may be a string (a table column name), or a hash (in which case the key is the as value, and the value is used as the select expression). 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.)

Value: \@columns

Indicates additional columns to be selected from storage. Works the same as columns but adds columns to the selection. (You may also use the include_columns attribute, as in earlier versions of DBIC). For example:-

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

would return all CDs and include a 'name' column to the information passed to object inflation. Note that the 'artist' is the name of the column (or relationship) accessor, and 'name' is the name of the column accessor in the related table.

Value: \@columns

Deprecated. Acts as a synonym for +columns for backward compatibility.

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.

NOTE: You will almost always need a corresponding 'as' entry when you use 'select'.

Indicates additional columns to be selected from storage. Works the same as select but adds columns to the selection.

Indicates additional column names for those added via +select. See as.

Value: \@inflation_names

Indicates column names for object inflation. That is, as indicates the name that the column can be accessed as via the get_column method (or via the object accessor, if one already exists). It has nothing to do with the SQL code SELECT foo AS bar.

The as attribute 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.

Please note: This will NOT insert an AS employee_count into the SQL statement produced, it is used for internal access only. Thus attempting to use the accessor in an order_by clause or similar will fail miserably.

To get around this limitation, you can supply literal SQL to your select attibute that contains the AS alias text, eg:

  select => [\'myfield AS alias']

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',
    }
  );

You need to use the relationship (not the table) name in conditions, because they are aliased as such. The current table is aliased as "me", so you need to use me.column_name in order to avoid ambiguity. For example:

  # Get CDs from 1984 with a 'Foo' track
  my $rs = $schema->resultset('CD')->search(
    {
      'me.year' => 1984,
      'tracks.name' => 'Foo'
    },
    { join => 'tracks' }
  );

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.

For more help on using joins with search, see DBIx::Class::Manual::Joining.

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 the data will already be available, without extra queries to the database). 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.

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'). A more complex example that prefetches an artists cds, the tracks on those cds, and the tags associted with that artist is given below (assuming many-to-many from artists to tags):

 my $rs = $schema->resultset('Artist')->search(
   undef,
   {
     prefetch => [
       { cds => 'tracks' },
       { artist_tags => 'tags' }
     ]
   }
 );

NOTE: If you specify a prefetch attribute, the join and select attributes will be ignored.

CAVEATs: Prefetch does a lot of deep magic. As such, it may not behave exactly as you might expect.

• Prefetch uses the cache to populate the prefetched relationships. This may or may not be what you want.
• If you specify a condition on a prefetched relationship, ONLY those rows that match the prefetched condition will be fetched into that relationship. This means that adding prefetch to a search() may alter what is returned by traversing a relationship. So, if you have Artist->has_many(CDs) and you do
  
  

    my $artist_rs = $schema->resultset('Artist')->search({
        'cds.year' => 2008,
    }, {
        join => 'cds',
    });
  
  

  
  
  

    my $count = $artist_rs->first->cds->count;
  
  

  
  
  

    my $artist_rs_prefetch = $artist_rs->search( {}, { prefetch => 'cds' } );
  
  

  
  
  

    my $prefetch_count = $artist_rs_prefetch->first->cds->count;
  
  

  
  
  

    cmp_ok( $count, '==', $prefetch_count, "Counts should be the same" );
  
  

  
  
  that cmp_ok() may or may not pass depending on the datasets involved. This behavior may or may not survive the 0.09 transition.

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.

If rows attribute is not specified it defaults to 10 rows per page.

When you have a paged resultset, count will only return the number of rows in the page. To get the total, use the pager and call total_entries on it.

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.

Value: $offset

Specifies the (zero-based) row number for the first row to be returned, or the of the first row of the first page if paging is used.

Value: \@columns

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

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

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 } }

Value: (0 | 1)

Set to 1 to group by all columns. If the resultset already has a group_by attribute, this setting is ignored and an appropriate warning is issued.

Adds to the WHERE clause.

  # only return rows WHERE deleted IS NULL for all searches
  __PACKAGE__->resultset_attributes({ where => { deleted => undef } }); )

Can be overridden by passing { where => undef } as an attribute to a resultset.

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.

Value: ( 'update' | 'shared' )

Set to 'update' for a SELECT ... FOR UPDATE or 'shared' for a SELECT ... FOR SHARED.