DBIx::Class::ResultSet man page on MacOSX

Man page or keyword search:  
man Server   23457 pages
apropos Keyword Search (all sections)
Output format
MacOSX logo
[printable version]

DBIx::Class::ResultSetUser Contributed Perl DocumentaDBIx::Class::ResultSet(3)

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

SYNOPSIS
	 my $users_rs	= $schema->resultset('User');
	 while( $user = $users_rs->next) {
	   print $user->username;
	 }

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

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

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

CUSTOM ResultSet CLASSES THAT USE Moose
       If you want to make your custom ResultSet classes with Moose, use a
       template similar to:

	   package MyApp::Schema::ResultSet::User;

	   use Moose;
	   use namespace::autoclean;
	   use MooseX::NonMoose;
	   extends 'DBIx::Class::ResultSet';

	   sub BUILDARGS { $_[2] }

	   ...your code...

	   __PACKAGE__->meta->make_immutable;

	   1;

       The MooseX::NonMoose is necessary so that the Moose constructor does
       not clash with the regular ResultSet constructor. Alternatively, you
       can use:

	   __PACKAGE__->meta->make_immutable(inline_constructor => 0);

       The BUILDARGS is necessary because the signature of the ResultSet "new"
       is "->new($source, \%args)".

EXAMPLES
   Chaining resultsets
       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->result_source->schema;

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

	   $cd_rs = $self->apply_security_policy( $cd_rs );

	   return $cd_rs->all();
	 }

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

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

       Resolving conditions and attributes

       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" and "having" attributes, 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.

   Multiple queries
       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".

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

       In list context, "->all()" is called implicitly on the resultset, thus
       returning a list of row objects instead. To avoid that, use
       "search_rs".

       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 SQL::Abstract
       and its extension DBIx::Class::SQLMaker.

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

       CAVEAT

       Note that "search" does not process/deflate any of the values passed in
       the SQL::Abstract-compatible search condition structure. This is unlike
       other condition-bound methods "new", "create" and "find". The user must
       ensure manually that any value passed to this method will stringify to
       something the RDBMS knows how to deal with. A notable example is the
       handling of DateTime objects, for more info see: "Formatting DateTime
       objects in queries" in DBIx::Class::Manual::Cookbook.

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

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

   find
       Arguments: \%columns_values | @pk_values, \%attrs?
       Return Value: $row_object | undef

       Finds and returns a single row based on supplied criteria. Takes either
       a hashref with the same format as "create" (including inference of
       foreign keys from related objects), or a list of primary key values in
       the same order as the primary columns declaration on the
       "result_source".

       In either case an attempt is made to combine conditions already
       existing on the resultset with the condition passed to this method.

       To aid with preparing the correct query for the storage you may supply
       the "key" attribute, which is the name of a unique constraint (the
       unique constraint corresponding to the primary columns is always named
       "primary"). If the "key" attribute has been supplied, and DBIC is
       unable to construct a query that satisfies the named unique constraint
       fully ( non-NULL values for each column member of the constraint) an
       exception is thrown.

       If no "key" is specified, the search is carried over all unique
       constraints which are fully defined by the available condition.

       If no such constraint is found, "find" currently defaults to a simple
       "search->(\%column_values)" which may or may not do what you expect.
       Note that this fallback behavior may be deprecated in further versions.
       If you need to search with arbitrary conditions - use "search". If the
       query resulting from this fallback produces more than one row, a
       warning to the effect is issued, though only the first row is
       constructed and returned as $row_object.

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

       Note that if you have extra concerns about the correctness of the
       resulting query you need to specify the "key" attribute and supply the
       entire condition as an argument to find (since it is not always
       possible to perform the combination of the resultset condition with the
       supplied one, especially if the resultset condition contains literal
       sql).

       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:

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

       See also "find_or_create" and "update_or_create".

   search_related
       Arguments: $rel, $cond?, \%attrs?
       Return Value: $new_resultset (scalar context) || @row_objs (list
       context)

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

       In list context, "->all()" is called implicitly on the resultset, thus
       returning a list of row objects instead. To avoid that, use
       "search_related_rs".

       See also "search_related_rs".

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

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

	 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 "undef". 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
	   preceding 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.

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

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

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

       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.

   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.

       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.

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

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

   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.

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

   first
       Arguments: none
       Return Value: $object | undef

       Resets the resultset and returns an object for the first result (or
       "undef" if the resultset is empty).

   update
       Arguments: \%values
       Return Value: $storage_rv

       Sets the specified columns in the resultset to the supplied values in a
       single query. Note that this will not run any
       accessor/set_column/update triggers, nor will it update any row object
       instances derived from this resultset (this includes the contents of
       the resultset cache if any). See "update_all" if you need to execute
       any on-update triggers or cascades defined either by you or a result
       component.

       The return value is a pass through of what the underlying storage
       backend returned, and may vary. See "execute" in DBI for the most
       common case.

       CAVEAT

       Note that "update" does not process/deflate any of the values passed
       in.  This is unlike the corresponding "update" in DBIx::Class::Row. The
       user must ensure manually that any value passed to this method will
       stringify to something the RDBMS knows how to deal with. A notable
       example is the handling of DateTime objects, for more info see:
       "Formatting DateTime objects in queries" in
       DBIx::Class::Manual::Cookbook.

   update_all
       Arguments: \%values
       Return Value: 1

       Fetches all objects and updates them one at a time via "update" in
       DBIx::Class::Row. Note that "update_all" will run DBIC defined
       triggers, while "update" will not.

   delete
       Arguments: none
       Return Value: $storage_rv

       Deletes the rows matching this resultset in a single query. Note that
       this will not run any delete triggers, nor will it alter the in_storage
       status of any row object instances derived from this resultset (this
       includes the contents of the resultset cache if any). See "delete_all"
       if you need to execute any on-delete triggers or cascades defined
       either by you or a result component.

       The return value is a pass through of what the underlying storage
       backend returned, and may vary. See "execute" in DBI for the most
       common case.

   delete_all
       Arguments: none
       Return Value: 1

       Fetches all objects and deletes them one at a time via "delete" in
       DBIx::Class::Row. Note that "delete_all" will run DBIC defined
       triggers, while "delete" will not.

   populate
       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 for submitting 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.

   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.

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

   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: $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.

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

   find_or_new
       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 using "find". 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: Make sure to read the documentation of "find" and understand the
       significance of the "key" attribute, as its lack may skew your search,
       and subsequently result in spurious new objects.

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

   create
       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 transparently 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_to" resultset. 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.

   find_or_create
       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: Make sure to read the documentation of "find" and understand the
       significance of the "key" attribute, as its lack may skew your search,
       and subsequently result in spurious row creation.

       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.

       If you need to know if an existing row was found or a new one created
       use "find_or_new" and "in_storage" in DBIx::Class::Row instead. Don't
       forget to call "insert" in DBIx::Class::Row to save the newly created
       row to the database!

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

	 if( $cd->in_storage ) {
	     # do some stuff
	     $cd->insert;
	 }

   update_or_create
       Arguments: \%col_values, { key => $unique_constraint }?
       Return Value: $row_object

	 $resultset->update_or_create({ col => $val, ... });

       Like "find_or_create", but if a row is found it is immediately updated
       via "$found_row->update (\%col_values)".

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

       Note: Make sure to read the documentation of "find" and understand the
       significance of the "key" attribute, as its lack may skew your search,
       and subsequently result in spurious row creation.

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

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

       If you need to know if an existing row was updated or a new one created
       use "update_or_new" and "in_storage" in DBIx::Class::Row instead. Don't
       forget to call "insert" in DBIx::Class::Row to save the newly created
       row to the database!

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

	 if( $cd->in_storage ) {
	     # do some stuff
	     $cd->insert;
	 }

   update_or_new
       Arguments: \%col_values, { key => $unique_constraint }?
       Return Value: $rowobject

	 $resultset->update_or_new({ col => $val, ... });

       Like "find_or_new" but if a row is found it is immediately updated via
       "$found_row->update (\%col_values)".

       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: Make sure to read the documentation of "find" and understand the
       significance of the "key" attribute, as its lack may skew your search,
       and subsequently result in spurious new objects.

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

   get_cache
       Arguments: none
       Return Value: \@cache_objects | undef

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

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

   clear_cache
       Arguments: none
       Return Value: undef

       Clears the cache for the resultset.

   is_paged
       Arguments: none
       Return Value: true, if the resultset has been paginated

   is_ordered
       Arguments: none
       Return Value: true, if the resultset has been ordered with "order_by".

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

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

   as_subselect_rs
       Arguments: none
       Return Value: $resultset

       Act as a barrier to SQL symbols.	 The resultset provided will be made
       into a "virtual view" by including it as a subquery within the from
       clause.	From this point on, any joined tables are inaccessible to
       ->search on the resultset (as if it were simply where-filtered without
       joins).	For example:

	my $rs = $schema->resultset('Bar')->search({'x.name' => 'abc'},{ join => 'x' });

	# 'x' now pollutes the query namespace

	# So the following works as expected
	my $ok_rs = $rs->search({'x.other' => 1});

	# But this doesn't: instead of finding a 'Bar' related to two x rows (abc and
	# def) we look for one row with contradictory terms and join in another table
	# (aliased 'x_2') which we never use
	my $broken_rs = $rs->search({'x.name' => 'def'});

	my $rs2 = $rs->as_subselect_rs;

	# doesn't work - 'x' is no longer accessible in $rs2, having been sealed away
	my $not_joined_rs = $rs2->search({'x.other' => 1});

	# works as expected: finds a 'table' row related to two x rows (abc and def)
	my $correctly_joined_rs = $rs2->search({'x.name' => 'def'});

       Another example of when one might use this would be to select a subset
       of columns in a group by clause:

	my $rs = $schema->resultset('Bar')->search(undef, {
	  group_by => [qw{ id foo_id baz_id }],
	})->as_subselect_rs->search(undef, {
	  columns => [qw{ id foo_id }]
	});

       In the above example normally columns would have to be equal to the
       group by, but because we isolated the group by into a subselect the
       above works.

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

ATTRIBUTES
       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:

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

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

       Essentially "columns" does the same as "select" and "as".

	   columns => [ 'foo', { bar => 'baz' } ]

       is the same as

	   select => [qw/foo baz/],
	   as => [qw/foo bar/]

   +columns
       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.

       NOTE: You need to explicitly quote '+columns' when defining the
       attribute.  Not doing so causes Perl to incorrectly interpret +columns
       as a bareword with a unary plus operator before it.

   include_columns
       Value: \@columns

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

   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' },
	     { max => { length => 'name' }, -as => 'longest_name' }
	   ]
	 });

	 # Equivalent SQL
	 SELECT name, COUNT( employeeid ), MAX( LENGTH( name ) ) AS longest_name FROM employee

       NOTE: You will almost always need a corresponding "as" attribute when
       you use "select", to instruct DBIx::Class how to store the result of
       the column.  Also note that the "as" attribute has nothing to do with
       the SQL-side 'AS' identifier aliasing. You can however alias a
       function, so you can use it in e.g. an "ORDER BY" clause. This is done
       via the "-as" select function attribute supplied as shown in the
       example above.

       NOTE: You need to explicitly quote '+select'/'+as' when defining the
       attributes.  Not doing so causes Perl to incorrectly interpret them as
       a bareword with a unary plus operator before it.

   +select
	   Indicates additional columns to be selected from storage.  Works
	   the same as "select" but adds columns to the default selection,
	   instead of specifying an explicit list.

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

   as
       Value: \@inflation_names

       Indicates column names for object inflation. That is "as" indicates the
       slot name in which the column value will be stored within the Row
       object. The value will then be accessible via this identifier by the
       "get_column" method (or via the object accessor if one with the same
       name already exists) as shown below. The "as" attribute has nothing to
       do with the SQL-side "AS". See "select" for details.

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

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

       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.

   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 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 any of the relationship types and
       multiple prefetches can be specified together. Below is a more complex
       example that prefetches a CD's artist, its liner notes (if present),
       the cover image, the tracks on that cd, and the guests on those tracks.

	# Assuming:
	My::Schema::CD->belongs_to( artist	=> 'My::Schema::Artist'	    );
	My::Schema::CD->might_have( liner_note	=> 'My::Schema::LinerNotes' );
	My::Schema::CD->has_one(    cover_image => 'My::Schema::Artwork'    );
	My::Schema::CD->has_many(   tracks	=> 'My::Schema::Track'	    );

	My::Schema::Artist->belongs_to( record_label => 'My::Schema::RecordLabel' );

	My::Schema::Track->has_many( guests => 'My::Schema::Guest' );

	my $rs = $schema->resultset('CD')->search(
	  undef,
	  {
	    prefetch => [
	      { artist => 'record_label'},  # belongs_to => belongs_to
	      'liner_note',		    # might_have
	      'cover_image',		    # has_one
	      { tracks => 'guests' },	    # has_many => has_many
	    ]
	  }
	);

       This will produce SQL like the following:

	SELECT cd.*, artist.*, record_label.*, liner_note.*, cover_image.*,
	       tracks.*, guests.*
	  FROM cd me
	  JOIN artist artist
	    ON artist.artistid = me.artistid
	  JOIN record_label record_label
	    ON record_label.labelid = artist.labelid
	  LEFT JOIN track tracks
	    ON tracks.cdid = me.cdid
	  LEFT JOIN guest guests
	    ON guests.trackid = track.trackid
	  LEFT JOIN liner_notes liner_note
	    ON liner_note.cdid = me.cdid
	  JOIN cd_artwork cover_image
	    ON cover_image.cdid = me.cdid
	ORDER BY tracks.cd

       Now the "artist", "record_label", "liner_note", "cover_image",
       "tracks", and "guests" of the CD will all be available through the
       relationship accessors without the need for additional queries to the
       database.

       However, there is one caveat to be observed: it can be dangerous to
       prefetch more than one has_many relationship on a given level. e.g.:

	my $rs = $schema->resultset('CD')->search(
	  undef,
	  {
	    prefetch => [
	      'tracks',				# has_many
	      { cd_to_producer => 'producer' }, # has_many => belongs_to (i.e. m2m)
	    ]
	  }
	);

       In fact, "DBIx::Class" will emit the following warning:

	Prefetching multiple has_many rels tracks and cd_to_producer at top
	level will explode the number of row objects retrievable via ->next
	or ->all. Use at your own risk.

       The collapser currently can't identify duplicate tuples for multiple
       has_many relationships and as a result the second has_many relation
       could contain redundant objects.

       Using "prefetch" with "join"

       "prefetch" implies a "join" with the equivalent argument, and is
       properly merged with any existing "join" specification. So the
       following:

	 my $rs = $schema->resultset('CD')->search(
	  {'record_label.name' => 'Music Product Ltd.'},
	  {
	    join     => {artist => 'record_label'},
	    prefetch => 'artist',
	  }
	);

       ... will work, searching on the record label's name, but only
       prefetching the "artist".

       Using "prefetch" with "select" / "+select" / "as" / "+as"

       "prefetch" implies a "+select"/"+as" with the fields of the prefetched
       relations.  So given:

	 my $rs = $schema->resultset('CD')->search(
	  undef,
	  {
	    select   => ['cd.title'],
	    as	     => ['cd_title'],
	    prefetch => 'artist',
	  }
	);

       The "select" becomes: 'cd.title', 'artist.*' and the "as" becomes:
       'cd_title', 'artist.*'.

       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.

   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.

       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.

   rows
       Value: $rows

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

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

   software_limit
       Value: (0 | 1)

       When combined with "rows" and/or "offset" the generated SQL will not
       include any limit dialect stanzas. Instead the entire result will be
       selected as if no limits were specified, and DBIC will perform the
       limit locally, by artificially advancing and finishing the resulting
       "cursor".

       This is the recommended way of performing resultset limiting when no
       sane RDBMS implementation is available (e.g.  Sybase ASE using the
       Generic Sub Query hack)

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

       or with an in-place function in which case literal SQL is required:

	 having => \[ 'count(employee) >= ?', [ count => 100 ] ]

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

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

	   For more complicated where clauses see "WHERE CLAUSES" in
	   SQL::Abstract.

   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.

   for
       Value: ( 'update' | 'shared' )

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

perl v5.16.2			  2012-10-18	     DBIx::Class::ResultSet(3)
[top]

List of man pages available for MacOSX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net