| DBIx::Class::ResultSet - Responsible for fetching and creating resultset. |
DBIx::Class::ResultSet - Responsible for fetching and creating resultset.
my $rs = $schema->resultset('User')->search(registered => 1);
my @rows = $schema->resultset('CD')->search(year => 2005);
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;
The resultset constructor. Takes a source object (usually a the DBIx::Class::ResultSourceProxy::Table manpage) 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.
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. For a complete
documentation for the first argument, see the SQL::Abstract manpage.
This method does the same exact thing as search() except it will
always return a resultset, even in 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.
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, 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.
See also find_or_create and update_or_create. For information on how to declare unique constraints, see add_unique_constraint in the DBIx::Class::ResultSource manpage.
$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.
Returns a storage-driven cursor to the given resultset. See the DBIx::Class::Cursor manpage for more information.
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.
my $max_length = $rs->get_column('length')->max;
Returns a the DBIx::Class::ResultSetColumn manpage instance for a column of the ResultSet.
# 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 the DBIx::Class::Manual::Cookbook manpage.
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);
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.
An accessor for the primary ResultSource object from which this ResultSet is derived.
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.
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, the DBIX::Class manpage 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.
Counts the results in a literal query. Equivalent to calling search_literal with the passed arguments, then count.
Returns all elements in the resultset. Called implicitly if the resultset is returned in list context.
Resets the resultset's cursor, so you can iterate through the elements again.
Resets the resultset and returns an object for the first result (if the resultset returns anything).
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.
Fetches all objects and updates them one at a time. Note that update_all
will run DBIC cascade triggers, while update will not.
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 the DBIx::Class::Row manpage.
Fetches all objects and deletes them one at a time. Note that delete_all
will run DBIC cascade triggers, while delete will not.
Pass an arrayref of hashrefs. Each hashref should be a structure suitable for
submitting to a $resultset->create(...) method.
In void context, insert_bulk in the DBIx::Class::Storage::DBI manpage 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 the DBIx::Class::ResultSet manpage, and a arrayref of the resulting row objects is returned.
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'
Please note an important effect on your data when choosing between void and
wantarray context. Since void context goes straight to C<insert_bulk> in
L<DBIx::Class::Storage::DBI> this will skip any component that is overriding
c<insert>. So if you are using something like L<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.
Return Value a the Data::Page manpage object for the current resultset. Only makes
sense for queries with a page attribute.
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).
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 the DBIx::Class::Row manpage to do that. Calling in_storage in the DBIx::Class::Row manpage will tell you whether the row object has been inserted or not.
Passes the hashref of input on to new in the DBIx::Class::Row manpage.
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 the DBIx::Class::Row manpage on it.
If you want objects to be saved immediately, use find_or_create instead.
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 it's primary key.
To create related objects, pass a hashref for the value if the related
item is a foreign key relationship (belongs_to in the DBIx::Class::Relationship manpage),
and use the name of the relationship as the key. (NOT the name of the field,
necessarily). For has_many and has_one relationships, pass an arrayref
of hashrefs containing the data for each of the rows to create in the foreign
tables, again using the relationship name as the key.
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 C<has_many>
or C<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",
}
});
$class->find_or_create({ key => $val, ... });
Tries to find a record based on its primary key or unique constraint; 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' }
);
See also find and update_or_create. For information on how to declare unique constraints, see add_unique_constraint in the DBIx::Class::ResultSource manpage.
$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 => 'cd_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. For information on how to declare unique constraints, see add_unique_constraint in the DBIx::Class::ResultSource manpage.
Gets the contents of the cache for the resultset, if the cache is set.
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.
Clears the cache for the resultset.
Returns a related resultset for the supplied relationship name.
$artist_rs = $schema->resultset('CD')->related_resultset('Artist');
See throw_exception in the DBIx::Class::Schema manpage for details.
The resultset takes various attributes that modify its behavior. Here's an overview of them:
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 the DBIx::Class::Storage::DBI manpage) 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.)
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.)
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. 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.
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.
Indicates additional columns to be selected from storage. Works the same as the select manpage but adds columns to the selection.
Indicates additional column names for those added via +select.
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:
$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 the DBIx::Class::Manual::Cookbook manpage 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']
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.
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
the DBIx::Class manpage 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').
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 the rows manpage attribute is not specified it defualts to 10 rows per page.
Specifes the maximum number of rows for direct retrieval or the number of rows per page if the page attribute or method is used.
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.
A arrayref of columns to group by. Can include columns of joined tables.
group_by => [qw/ column1 column2 ... /]
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 } }
Set to 1 to group by all columns.
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 resulset.
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 the DBIx::Class::Manual::Cookbook manpage.
The from attribute gives you manual control over the FROM clause of SQL
statements generated by the DBIx::Class manpage, 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.
The syntax is as follows -
[
{ <alias1> => <table1> },
[
{ <alias2> => <table2>, -join_type => 'inner|left|right' },
[], # nested JOIN (optional)
{ <table1.column1> => <table2.column2>, ... (more conditions) },
],
# More of the above [ ] may follow for additional joins
]
<table1> <alias1>
JOIN
<table2> <alias2>
[JOIN ...]
ON <table1.column1> = <table2.column2>
<more joins may follow>
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
| DBIx::Class::ResultSet - Responsible for fetching and creating resultset. |