For a list of attributes that can be passed to search, see "ATTRIBUTES". For more examples of using this function, see Searching. For a complete documentation for the first argument, see SQL::Abstract.

search_rs

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.

search_related

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.

Can optionally take an additional condition *only* - this is a fast-code-path method; if you need to add extra joins or similar call ->search and then ->single without a condition on the $rs returned from that.

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.

result_class

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" class.

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.

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.

find_or_new

Arguments: \%vals, \%attrs?

Return Value: $object

Find an existing record from this resultset. 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.

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:

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.

throw_exception

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

Please note that if you have quote_char enabled (see "connect_info" in DBIx::Class::Storage::DBI) you will need to do \'year DESC' to specify an order. (The scalar ref causes it to be passed as raw sql to the DB, so you will need to manually quote things as appropriate.)

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

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.

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:

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.

+select

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

+as

as

Value: \@inflation_names

Indicates column names for object inflation. That is, c< 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:

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']

join

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

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

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:

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:

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

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.

from

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. And we really do mean "cannot", not just tried and failed. Attempting to use this because you're having problems with join is like trying to use x86 ASM because you've got a syntax error in your C. Trust us on this.

Now, if you're still really, really sure you need to use this (and if you're not 100% sure, ask the mailing list first), here's an explanation of how this works.