Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14) Standard preamble: ========================================================================
Class::DBI::Query - Deprecated SQL manager for Class::DBI
my $sth = Class::DBI::Query
owner => $class,
sqlname => $type,
essential => \@columns,
where_columns => \@where_cols,
This abstracts away many of the details of the Class::DBI underlying SQL mechanism. For the most part you probably don't want to be interfacing directly with this.
The underlying mechanisms are not yet stable, and are subject to change at any time.
A Query can have many options set before executing. Most can either be passed as an option to new(), or set later if you are building the query up dynamically:
The Class::DBI subclass that 'owns' this query. In the vast majority of cases a query will return objects - the owner is the class of which instances will be returned.
This should be the name of a query set up using set_sql.
This is the raw SQL that will substituted into the 'WHERE %s' in your query. If you have multiple %s's in your query then you should supply a listref of where_clauses. This SQL can include placeholders, which will be used when you call run().
When retrieving rows from the database that match the WHERE clause of the query, these are the columns that we fetch back and pre-load the resulting objects with. By default this is the Essential column group of the owner class.
This will extend your 'WHERE' clause by adding a 'AND $column = ?' (or whatever $match is, isntead of "=") for each column passed. If you have multiple WHERE clauses this will extend the last one.