Provided by: libdbix-class-perl_0.08250-2_all bug

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 (ie: "my $new_rs =
       $old_rs-"search(\%extra_cond, \%attrs)>), conditions and attributes with the same keys
       need resolving.

       If any of "columns", "select", "as" are present, they reset the original selection, and
       start the selection "clean".

       The "join", "prefetch", "+columns", "+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: $resultset

       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 never construct a resultset manually. Instead you get one from e.g. a
       "$schema->resultset('$source_name')" or "$another_resultset->search(...)" (the later
       called in scalar context):

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

       WARNING
           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, and is equivalent to:

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

           Please also keep in mind that many internals call "new_result" directly, so
           overloading this method with the idea of intercepting new result object creation will
           not work. See also warning pertaining to "create".

   search
       Arguments: $cond | undef, \%attrs?
       Return Value: $resultset (scalar context) | @result_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
       result 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_result", "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
       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".

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

       Arguments: $sql_fragment, @standalone_bind_values
       Return Value: $resultset (scalar context) | @result_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.

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

   find
       Arguments: \%columns_values | @pk_values, { key => $unique_constraint, %attrs }?
       Return Value: $result | 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 $result_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_name, $cond?, \%attrs?
       Return Value: $resultset (scalar context) | @result_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
       result 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: $result | 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) | @result_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) | @result_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 result 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
       CAVEAT: "count_literal" is provided for Class::DBI compatibility and should only be used
       in that context. See "search_literal" for further info.

       Arguments: $sql_fragment, @standalone_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: @result_objs

       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: $result | undef

       Resets the resultset (causing a fresh query to storage) and returns an object for the
       first result (or "undef" if the resultset is empty).

   update
       Arguments: \%values
       Return Value: $underlying_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
       result 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: $underlying_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 result 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: [ \@column_list, \@row_values+ ] | [ \%col_data+ ]
       Return Value: \@result_objects (scalar context) | @result_objects (list context)

       Accepts either an arrayref of hashrefs or alternatively an arrayref of arrayrefs.

       NOTE
           The context of this method call has an important effect on what is submitted to
           storage. In void context data is fed directly to fastpath insertion routines provided
           by the underlying storage (most often "execute_for_fetch" in DBI), bypassing the new
           and insert calls on the Result class, including any augmentation of these methods
           provided by components. For example 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 explicitly force scalar or list context in
           order to create those values.

       In non-void (scalar or list) context, this method is simply a wrapper for "create".
       Depending on list or scalar context either a list of Result objects or an arrayref
       containing these objects is returned.

       When supplying data in "arrayref of arrayrefs" invocation style, the first element should
       be a list of column names and each subsequent element should be a data value in the
       earlier specified column order.  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' ],
         ]);

       For the arrayref of hashrefs style each hashref should be a structure suitable for passing
       to "create". Multi-create is also permitted with this syntax.

         $schema->resultset("Artist")->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 }
             ],
            },
         ]);

       If you attempt a void-context multi-create as in the example above (each Artist also has
       the related list of CDs), and do not supply the necessary autoinc foreign key information,
       this method will proxy to the less efficient "create", and then throw the Result objects
       away. In this case there are obviously no benefits to using this method over "create".

   pager
       Arguments: none
       Return Value: $pager

       Returns 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: $resultset

       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: \%col_data
       Return Value: $result

       Creates a new result 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 result 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_values ]

       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: \%col_data, { key => $unique_constraint, %attrs }?
       Return Value: $result

         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: \%col_data
       Return Value: $result

       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_result"), will be inserted into
       their appropriate tables.

       Effectively a shortcut for "->new_result(\%col_data)->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"
           in DBIx::Class::Row or "insert" in DBIx::Class::Row depending on how early in the
           "create" process you need to intervene. See also warning pertaining to "new".

   find_or_create
       Arguments: \%col_data, { key => $unique_constraint, %attrs }?
       Return Value: $result

         $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_data, { key => $unique_constraint, %attrs }?
       Return Value: $result

         $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_data)".

       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!

   update_or_new
       Arguments: \%col_data, { key => $unique_constraint, %attrs }?
       Return Value: $result

         $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_data)".

       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: \@result_objs | 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: \@result_objs
       Return Value: \@result_objs

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

       Default attributes can be set on the result class using "resultset_attributes" in
       DBIx::Class::ResultSource.  (Please read the CAVEATS on that feature before using it!)

       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 | \%columns | $column

       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, but this is
       deprecated.)

       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, but this is deprecated). 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
       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.

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

   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.

        NOTE: An internal join-chain pruner will discard certain joins while
        constructing the actual SQL query, as long as the joins in question do not
        affect the retrieved result. This for example includes 1:1 left joins
        that are not part of the restriction specification (WHERE/HAVING) nor are
        a part of the query selection.

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

   collapse
       Value: (0 | 1)

       When set to a true value, indicates that any rows fetched from joined has_many
       relationships are to be aggregated into the corresponding "parent" object. For example,
       the resultset:

         my $rs = $schema->resultset('CD')->search({}, {
           '+columns' => [ qw/ tracks.title tracks.position / ],
           join => 'tracks',
           collapse => 1,
         });

       While executing the following query:

         SELECT me.*, tracks.title, tracks.position
           FROM cd me
           LEFT JOIN track tracks
             ON tracks.cdid = me.cdid

       Will return only as many objects as there are rows in the CD source, even though the
       result of the query may span many rows. Each of these CD objects will in turn have
       multiple "Track" objects hidden behind the has_many generated accessor "tracks". Without
       "collapse => 1", the return values of this resultset would be as many CD objects as there
       are tracks (a "Cartesian product"), with each CD object containing exactly one of all
       fetched Track data.

       When a collapse is requested on a non-ordered resultset, an order by some unique part of
       the main source (the left-most table) is inserted automatically.  This is done so that the
       resultset is allowed to be "lazy" - calling $rs->next will fetch only as many rows as it
       needs to build the next object with all of its related data.

       If an "order_by" is already declared, and orders the resultset in a way that makes
       collapsing as described above impossible (e.g. "ORDER BY has_many_rel.column" or "ORDER BY
       RANDOM()"), DBIC will automatically switch to "eager" mode and slurp the entire resultset
       before consturcting the first object returned by "next".

       Setting this attribute on a resultset that does not join any has_many relations is a no-
       op.

       For a more in-depth discussion, see "PREFETCHING".

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

       This attribute is a shorthand for specifying a "join" spec, adding all columns from the
       joined related sources as "+columns" and setting "collapse" to a true value. For example,
       the following two queries are equivalent:

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

       and

         my $rs = $schema->resultset('Artist')->search({}, {
           join => { cds => ['genre', 'tracks' ] },
           collapse => 1,
           '+columns' => [
             (map
               { +{ "cds.$_" => "cds.$_" } }
               $schema->source('Artist')->related_source('cds')->columns
             ),
             (map
               { +{ "cds.genre.$_" => "genre.$_" } }
               $schema->source('Artist')->related_source('cds')->related_source('genre')->columns
             ),
             (map
               { +{ "cds.tracks.$_" => "tracks.$_" } }
               $schema->source('Artist')->related_source('cds')->related_source('tracks')->columns
             ),
           ],
         });

       Both producing the following SQL:

         SELECT  me.artistid, me.name, me.rank, me.charfield,
                 cds.cdid, cds.artist, cds.title, cds.year, cds.genreid, cds.single_track,
                 genre.genreid, genre.name,
                 tracks.trackid, tracks.cd, tracks.position, tracks.title, tracks.last_updated_on, tracks.last_updated_at
           FROM artist me
           LEFT JOIN cd cds
             ON cds.artist = me.artistid
           LEFT JOIN genre genre
             ON genre.genreid = cds.genreid
           LEFT JOIN track tracks
             ON tracks.cd = cds.cdid
         ORDER BY me.artistid

       While "prefetch" implies a "join", it is ok to mix the two together, as the arguments are
       properly merged and generally do the right thing. For example, you may want to do the
       following:

         my $artists_and_cds_without_genre = $schema->resultset('Artist')->search(
           { 'genre.genreid' => undef },
           {
             join => { cds => 'genre' },
             prefetch => 'cds',
           }
         );

       Which generates the following SQL:

         SELECT  me.artistid, me.name, me.rank, me.charfield,
                 cds.cdid, cds.artist, cds.title, cds.year, cds.genreid, cds.single_track
           FROM artist me
           LEFT JOIN cd cds
             ON cds.artist = me.artistid
           LEFT JOIN genre genre
             ON genre.genreid = cds.genreid
         WHERE genre.genreid IS NULL
         ORDER BY me.artistid

       For a more in-depth discussion, see "PREFETCHING".

   alias
       Value: $source_alias

       Sets the source alias for the query.  Normally, this defaults to "me", but nested search
       queries (sub-SELECTs) might need specific aliases set to reference inner queries.  For
       example:

          my $q = $rs
             ->related_resultset('CDs')
             ->related_resultset('Tracks')
             ->search({
                'track.id' => { -ident => 'none_search.id' },
             })
             ->as_query;

          my $ids = $self->search({
             -not_exists => $q,
          }, {
             alias    => 'none_search',
             group_by => 'none_search.id',
          })->get_column('id')->as_query;

          $self->search({ id => { -in => $ids } })

       This attribute is directly tied to "current_source_alias".

   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' | \$scalar )

       Set to 'update' for a SELECT ... FOR UPDATE or 'shared' for a SELECT ... FOR SHARED. If
       \$scalar is passed, this is taken directly and embedded in the query.

PREFETCHING

       DBIx::Class supports arbitrary related data prefetching from multiple related sources. Any
       combination of relationship types and column sets are supported.  If collapsing is
       requested, there is an additional requirement of selecting enough data to make every
       individual object uniquely identifiable.

       Here are some more involved examples, based on the following relationship map:

         # Assuming:
         My::Schema::CD->belongs_to( artist      => 'My::Schema::Artist'     );
         My::Schema::CD->might_have( liner_note  => 'My::Schema::LinerNotes' );
         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('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.

       The "prefetch" attribute can be used with 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.

         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.

       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. In other words
           the "WHERE" condition would apply to the entire dataset, just like it would in regular
           SQL. If you want to add a condition only to the "right side" of a "LEFT JOIN" -
           consider declaring and using a relationship with a custom condition

DBIC BIND VALUES

       Because DBIC may need more information to bind values than just the column name and value
       itself, it uses a special format for both passing and receiving bind values.  Each bind
       value should be composed of an arrayref of "[ \%args => $val ]".  The format of "\%args"
       is currently:

       dbd_attrs
           If present (in any form), this is what is being passed directly to bind_param.  Note
           that different DBD's expect different bind args.  (e.g. DBD::SQLite takes a single
           numerical type, while DBD::Pg takes a hashref if bind options.)

           If this is specified, all other bind options described below are ignored.

       sqlt_datatype
           If present, this is used to infer the actual bind attribute by passing to
           "$resolved_storage->bind_attribute_by_data_type()".  Defaults to the "data_type" from
           the add_columns column info.

           Note that the data type is somewhat freeform (hence the sqlt_ prefix); currently
           drivers are expected to "Do the Right Thing" when given a common datatype name.  (Not
           ideal, but that's what we got at this point.)

       sqlt_size
           Currently used to correctly allocate buffers for bind_param_inout().  Defaults to
           "size" from the add_columns column info, or to a sensible value based on the
           "data_type".

       dbic_colname
           Used to fill in missing sqlt_datatype and sqlt_size attributes (if they are explicitly
           specified they are never overridden).  Also used by some weird DBDs, where the column
           name should be available at bind_param time (e.g. Oracle).

       For backwards compatibility and convenience, the following shortcuts are supported:

         [ $name => $val ] === [ { dbic_colname => $name }, $val ]
         [ \$dt  => $val ] === [ { sqlt_datatype => $dt }, $val ]
         [ undef,   $val ] === [ {}, $val ]
         $val              === [ {}, $val ]

AUTHOR AND CONTRIBUTORS

       See AUTHOR and CONTRIBUTORS in DBIx::Class

LICENSE

       You may distribute this code under the same terms as Perl itself.