| DBIx::Class::Manual::FAQ - Frequently Asked Questions |
DBIx::Class::Manual::FAQ - Frequently Asked Questions (in theory)
This document is intended as an anti-map of the documentation. If you know what you want to do, but not how to do it in the DBIx::Class manpage, then look here. It does not contain much code or examples, it just gives explanations and pointers to the correct pieces of documentation to read.
How Do I:
First, choose a database. For testing/experimenting, we reccommend the DBD::SQLite manpage, which is a self-contained small database (i.e. all you need to do is to install the DBD::SQLite manpage from CPAN, and it's usable).
Next, spend some time defining which data you need to store, and how it relates to the other data you have. For some help on normalisation, go to http://b62.tripod.com/doc/dbbase.htm or http://209.197.234.36/db/simple.html.
Now, decide whether you want to have the database itself be the definitive source of information about the data layout, or your DBIx::Class schema. If it's the former, look up the documentation for your database, eg. http://sqlite.org/lang_createtable.html, on how to create tables, and start creating them. For a nice universal interface to your database, you can try the DBI::Shell manpage. If you decided on the latter choice, read the FAQ on setting up your classes manually, and the one on creating tables from your schema.
Install the Catalyst::Model::DBIC::Schema manpage from CPAN. See its documentation, or below, for further details.
Install the DBIx::Class::Schema::Loader manpage from CPAN, and read its documentation.
Look at the the DBIx::Class::Manual::Example manpage and come back here if you get lost.
Create your classes manually, as above. Write a script that calls deploy in the DBIx::Class::Schema manpage. See there for details, or the the DBIx::Class::Manual::Cookbook manpage.
Once you have created all the appropriate table/source classes, and an overall Schema class, you can start using them in an application. To do this, you need to create a central Schema object, which is used to access all the data in the various tables. See connect in the DBIx::Class::Schema manpage for details. The actual connection does not happen until you actually request data, so don't be alarmed if the error from incorrect connection details happens a lot later.
If your database server allows you to run querys across multiple databases at once, then so can DBIx::Class. All you need to do is make sure you write the database name as part of the table in the DBIx::Class::ResultSource manpage call. Eg:
__PACKAGE__->table('mydb.mytablename');
And load all the Result classes for both / all databases using one load_namespaces in the DBIx::Class::Schema manpage call.
Add the name of the schema to the table in the DBIx::Class::ResultSource manpage as part of the name, and make sure you give the one user you are going to connect with rights to read/write all the schemas/tables as necessary.
There are a variety of relationship types that come pre-defined for you to use. These are all listed in the DBIx::Class::Relationship manpage. If you need a non-standard type, or more information, look in the DBIx::Class::Relationship::Base manpage.
This is called a has_many relationship on the one side, and a
belongs_to relationship on the many side. Currently these need to
be set up individually on each side. See the DBIx::Class::Relationship manpage
for details.
Create a belongs_to relationship for the field containing the
foreign key. See belongs_to in the DBIx::Class::Relationship manpage.
Just create a belongs_to relationship, as above. If the column is
NULL then the inflation to the foreign object will not happen. This
has a side effect of not always fetching all the relevant data, if you
use a nullable foreign-key relationship in a JOIN, then you probably
want to set the join_type to left.
Instead of supplying a single column name, all relationship types also allow you to supply a hashref containing the condition across which the tables are to be joined. The condition may contain as many fields as you like. See the DBIx::Class::Relationship::Base manpage.
Read the documentation on many_to_many in the DBIx::Class::Relationship manpage.
By default, DBIx::Class cascades deletes and updates across
has_many and might_have relationships. You can disable this
behaviour on a per-relationship basis by supplying
cascade_delete => 0 in the relationship attributes.
The cascaded operations are performed after the requested delete or update, so if your database has a constraint on the relationship, it will have deleted/updated the related records or raised an exception before DBIx::Class gets to perform the cascaded operation.
Use its name. An accessor is created using the name. See examples in Using relationships in the DBIx::Class::Manual::Cookbook manpage.
Create a $schema object, as mentioned above in ".. connect to my
database". Find the ResultSet
that you want to search in, and call search on it. See
search in the DBIx::Class::ResultSet manpage.
Supplying something like:
->search({'mydatefield' => 'now()'})
to search, will probably not do what you expect. It will quote the text "now()", instead of trying to call the function. To provide literal, unquoted text you need to pass in a scalar reference, like so:
->search({'mydatefield' => \'now()'})
Supply a list of columns you want to sort by to the order_by
attribute. See order_by in the DBIx::Class::ResultSet manpage.
as?
You don't. You'll need to supply the same functions/expressions to
order_by, as you did to select.
To get "fieldname AS alias" in your SQL, you'll need to supply a
literal chunk of SQL in your select attribute, such as:
->search({}, { select => [ \'now() AS currenttime'] })
Then you can use the alias in your order_by attribute.
Supply a list of columns you want to group on, to the group_by
attribute, see group_by in the DBIx::Class::ResultSet manpage.
as?
You don't. You'll need to supply the same functions/expressions to
group_by, as you did to select.
To get "fieldname AS alias" in your SQL, you'll need to supply a
literal chunk of SQL in your select attribute, such as:
->search({}, { select => [ \'now() AS currenttime'] })
Then you can use the alias in your group_by attribute.
The first argument to search is a hashref of accessor names and
values to filter them by, for example:
->search({'created_time' => { '>=', '2006-06-01 00:00:00' } })
Note that to use a function here you need to make the whole value into a scalar reference:
->search({'created_time' => \'>= yesterday()' })
To search in two related tables, you first need to set up appropriate
relationships between their respective classes. When searching you
then supply the name of the relationship to the join attribute in
your search, for example when searching in the Books table for all the
books by the author "Fred Bloggs":
->search({'authors.name' => 'Fred Bloggs'}, { join => 'authors' })
The type of join created in your SQL depends on the type of relationship between the two tables, see the DBIx::Class::Relationship manpage for the join used by each relationship.
Currently, the DBIx::Class manpage can only create join conditions using
equality, so you're probably better off creating a view in your
database, and using that as your source. A view is a stored SQL
query, which can be accessed similarly to a table, see your database
documentation for details.
To use functions or literal SQL with conditions other than equality you need to supply the entire condition, for example:
my $interval = "< now() - interval '12 hours'"; ->search({last_attempt => \$interval})
and not:
my $interval = "now() - interval '12 hours'"; ->search({last_attempt => { '<' => \$interval } })
To use an SQL function on the left hand side of a comparison:
->search({}, { where => \'YEAR(date_of_birth)=1979' });
Or, if you have quoting off:
->search({ 'YEAR(date_of_birth)' => 1979 });
Behind the scenes, DBIx::Class uses the SQL::Abstract manpage to help construct its SQL searches. So if you fail to find help in the the DBIx::Class::Manual::Cookbook manpage, try looking in the SQL::Abstract documentation.
To make Oracle behave like most RDBMS use on_connect_do to issue alter session statements on database connection establishment:
->on_connect_do("ALTER SESSION SET NLS_COMP = 'LINGUISTIC'"); ->on_connect_do("ALTER SESSION SET NLS_SORT = '<NLS>_CI'"); e.g. ->on_connect_do("ALTER SESSION SET NLS_SORT = 'BINARY_CI'"); ->on_connect_do("ALTER SESSION SET NLS_SORT = 'GERMAN_CI'");
See the prefetch examples in the Cookbook.
Call get_column on a the DBIx::Class::ResultSet manpage, this returns a
the DBIx::Class::ResultSetColumn manpage, see it's documentation and the
Cookbook for details.
In your table schema class, create a "private" column accessor with:
__PACKAGE__->add_columns(my_column => { accessor => '_hidden_my_column' });
Then, in the same class, implement a subroutine called "my_column" that fetches the real value and does the formatting you want.
See the Cookbook for more details.
Sometimes you many only want a single record back from a search. A quick way to get that single row is to first run your search as usual:
->search->(undef, { order_by => "id DESC" })
Then call slice in the DBIx::Class::ResultSet manpage and ask it only to return 1 row:
->slice(0)
These two calls can be combined into a single statement:
->search->(undef, { order_by => "id DESC" })->slice(0)
Why slice instead of first in the DBIx::Class::ResultSet manpage or single in the DBIx::Class::ResultSet manpage? If supported by the database, slice will use LIMIT/OFFSET to hint to the database that we really only need one row. This can result in a significant speed improvement.
$row->discard_changes
Discarding changes and refreshing from storage are two sides fo the same coin. When you want to discard your local changes, just re-fetch the row from storage. When you want to get a new, fresh copy of the row, just re-fetch the row from storage. discard_changes in the DBIx::Class::PK manpage does just that by re-fetching the row from storage using the row's primary key.
Pass the rows and page attributes to your search, eg:
->search({}, { rows => 10, page => 1});
Call pager on the paged resultset, it will return a the Data::Page manpage
object. Calling total_entries on the pager will return the correct
total.
count on the resultset will only return the total number in the page.
In versions of the DBIx::Class manpage less than 0.07, you need to ensure your table class loads the PK::Auto component. This will attempt to fetch the value of your primary key from the database after the insert has happened, and store it in the created object. In versions 0.07 and above, this component is automatically loaded.
You need to create a trigger in your database that updates your
primary key field from the sequence. To help PK::Auto find your
inserted key, you can tell it the name of the sequence in the
column_info supplied with add_columns.
->add_columns({ id => { sequence => 'mysequence', auto_nextval => 1 } });
Create a resultset using a search, to filter the rows of data you would like to update, then call update on the resultset to change all the rows at once.
To stop the column name from being quoted, you'll need to supply a scalar reference:
->update({ somecolumn => \'othercolumn' })
But note that when using a scalar reference the column in the database will be updated but when you read the value from the object with e.g.
->somecolumn()
you still get back the scalar reference to the string, B<not> the new value in the database. To get that you must refresh the row from storage using C<discard_changes()>. Or chain your function calls like this:
->update->discard_changes to update the database and refresh the object in one step. =item .. store JSON/YAML in a column and have it deflate/inflate automatically?
You can use the DBIx::Class::InflateColumn manpage to accomplish YAML/JSON storage transparently.
If you want to use JSON, then in your table schema class, do the following:
use JSON;
__PACKAGE__->add_columns(qw/ ... my_column ../) __PACKAGE__->inflate_column('my_column', { inflate => sub { jsonToObj(shift) }, deflate => sub { objToJson(shift) }, });
For YAML, in your table schema class, do the following:
use YAML;
__PACKAGE__->add_columns(qw/ ... my_column ../) __PACKAGE__->inflate_column('my_column', { inflate => sub { YAML::Load(shift) }, deflate => sub { YAML::Dump(shift) }, });
This technique is an easy way to store supplemental unstructured data in a table. Be careful not to overuse this capability, however. If you find yourself depending more and more on some data within the inflated column, then it may be time to factor that data out.
You can add your own data accessors to your classes.
One method is to use the built in mk_group_accessors (via the Class::Accessor::Grouped manpage)
package MyTable;
use parent 'DBIx::Class';
__PACKAGE__->table('foo'); #etc
__PACKAGE__->mk_group_accessors('simple' => qw/non_column_data/); # must use simple group
An another method is to use Moose with your the DBIx::Class manpage package.
package MyTable;
use Moose; # import Moose
use Moose::Util::TypeConstraint; # import Moose accessor type constraints
extends 'DBIx::Class'; # Moose changes the way we define our parent (base) package
has 'non_column_data' => ( is => 'rw', isa => 'Str' ); # define a simple attribute
__PACKAGE__->table('foo'); # etc
With either of these methods the resulting use of the accesssor would be
my $row;
# assume that some where in here $row will get assigned to a MyTable row
$row->non_column_data('some string'); # would set the non_column_data accessor
# some other stuff happens here
$row->update(); # would not inline the non_column_data accessor into the update
=item How do I use DBIx::Class objects in my TT templates?
Like normal objects, mostly. However you need to watch out for TT calling methods in list context. When calling relationship accessors you will not get resultsets, but a list of all the related objects.
Starting with version 0.07, you can use search_rs in the DBIx::Class::ResultSet manpage to work around this issue.
Turn on debugging! See the DBIx::Class::Storage manpage for details of how to turn on debugging in the environment, pass your own filehandle to save debug to, or create your own callback.
the DBIx::Class manpage runs the actual SQL statement as late as possible, thus
if you create a resultset using search in scalar context, no query
is executed. You can create further resultset refinements by calling
search again or relationship accessors. The SQL query is only run when
you ask the resultset for an actual row object.
If your table lacks a primary key, DBIx::Class can't work out which row it should operate on, for example to delete or update. However, a UNIQUE constraint on one or more columns allows DBIx::Class to uniquely identify the row, so you can tell the DBIx::Class::ResultSource manpage these columns act as a primary key, even if they don't from the database's point of view:
$resultset->set_primary_key(@column);
Look at the tips in STARTUP SPEED in the DBIx::Class::Manual::Cookbook manpage
You can reduce the overhead of object creation within the DBIx::Class manpage using the tips in Skip row object creation for faster results in the DBIx::Class::Manual::Cookbook manpage and Get raw data for blindingly fast results in the DBIx::Class::Manual::Cookbook manpage
See Stringification in the DBIx::Class::Manual::Cookbook manpage
If you get an error such as:
DBI connect('dbname=dbic','user',...) failed: could not connect to server:
No such file or directory Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
Likely you have/had two copies of postgresql installed simultaneously, the second one will use a default port of 5433, while the DBD::Pg manpage is compiled with a default port of 5432.
You can chance the port setting in postgresql.conf.
Stop mysqld and restart it with the --skip-grant-tables option.
Issue the following statements in the mysql client.
UPDATE mysql.user SET Password=PASSWORD('MyNewPass') WHERE User='root'; FLUSH PRIVILEGES;
Restart mysql.
Taken from:
http://dev.mysql.com/doc/refman/5.1/en/resetting-permissions.html.
| DBIx::Class::Manual::FAQ - Frequently Asked Questions |