DBIx::Class::Manual::FAQ(3) | User Contributed Perl Documentation | DBIx::Class::Manual::FAQ(3) |
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 DBIx::Class, 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:
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>.
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 DBI::Shell. 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.
__PACKAGE__->table('mydb.mytablename');
And load all the Result classes for both / all databases by calling "load_namespaces" in DBIx::Class::Schema.
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.
See DBIx::Class::Relationship.
->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()'})
->search({'created_time' => { '>=', '2006-06-01 00:00:00' } })
Note that to use a function here you need to make it a scalar reference:
->search({'created_time' => { '>=', \'yesterday()' } })
->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 DBIx::Class::Relationship for the join used by each relationship.
->search( \[ 'YEAR(date_of_birth) = ?', 1979 ] );
->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'");
The datetime_parser method on your storage object can be used to return the object that would normally do this, so it's easy to do it manually:
my $dtf = $schema->storage->datetime_parser; my $rs = $schema->resultset('users')->search( { signup_date => { -between => [ $dtf->format_datetime($dt_start), $dtf->format_datetime($dt_end), ], } }, );
With in a Result Class method, you can get this from the "result_source".
my $dtf = $self->result_source->storage->datetime_parser;
This kludge is necessary only for conditions passed to search and "find" in DBIx::Class::ResultSet, whereas create and "update" in DBIx::Class::Row (but not "update" in DBIx::Class::ResultSet) are DBIx::Class::InflateColumn-aware and will do the right thing when supplied an inflated DateTime object.
__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.
See also "Retrieve one and only one row from a resultset" in DBIx::Class::Manual::Cookbook.
A less readable way is to ask a regular search to return 1 row, using "slice" in DBIx::Class::ResultSet:
->search->(undef, { order_by => "id DESC" })->slice(0)
which (if supported by the database) will use LIMIT/OFFSET to hint to the database that we really only need one row. This can result in a significant speed improvement. The method using "single" in DBIx::Class::ResultSet mentioned in the cookbook can do the same if you pass a "rows" attribute to the search.
$result->discard_changes
Discarding changes and refreshing from storage are two sides of 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 DBIx::Class::Row does just that by re-fetching the row from storage using the row's primary key.
->search({}, { rows => 10, page => 1});
"count" on the resultset will only return the total number in the page.
->add_columns({ id => { sequence => 'mysequence', auto_nextval => 1 } });
DBIx::Class::Fixtures provides an alternative way to do this.
->update({ somecolumn => { -ident => 'othercolumn' } })
This method will not retrieve the new value and put it in your Row object. To fetch the new value, use the "discard_changes" method on the Row.
# will return the scalar reference: $result->somecolumn() # issue a select using the PK to re-fetch the row data: $result->discard_changes(); # Now returns the correct new value: $result->somecolumn()
To update and refresh at once, chain your calls:
$result->update({ 'somecolumn' => { -ident => 'othercolumn' } })->discard_changes;
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 custom methods that do arbitrary things, even to unrelated tables. For example, to provide a "$book->foo()" method which searches the cd table, you'd could add this to Book.pm:
sub foo { my ($self, $col_data) = @_; return $self->result_source->schema->resultset('cd')->search($col_data); }
And invoke that on any Book Result object like so:
my $rs = $book->foo({ title => 'Down to Earth' });
When two tables ARE related, DBIx::Class::Relationship::Base provides many methods to find or create data in related tables for you. But if you want to write your own methods, you can.
For example, to provide a "$book->foo()" method to manually implement what create_related() from DBIx::Class::Relationship::Base does, you could add this to Book.pm:
sub foo { my ($self, $rel_name, $col_data) = @_; return $self->related_resultset($rel_name)->create($col_data); }
Invoked like this:
my $author = $book->foo('author', { name => 'Fred' });
One method is to use the built in mk_group_accessors (via Class::Accessor::Grouped)
package App::Schema::Result::MyTable; use parent 'DBIx::Class::Core'; __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 DBIx::Class package.
package App::Schema::Result::MyTable; use Moose; # import Moose use Moose::Util::TypeConstraint; # import Moose accessor type constraints extends 'DBIx::Class::Core'; # 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 accessor would be
my $result; # assume that somewhere in here $result will get assigned to a MyTable row $result->non_column_data('some string'); # would set the non_column_data accessor # some other stuff happens here $result->update(); # would not inline the non_column_data accessor into the update
Use the "search_rs" in DBIx::Class::ResultSet method, or the relationship accessor methods ending with "_rs" to work around this issue.
See also "has_many" in DBIx::Class::Relationship.
For more info see DBIx::Class::Storage for details of how to turn on debugging in the environment, pass your own filehandle to save debug to, or create your own callback.
$resultset->set_primary_key(@column);
package Your::Schema::Group; use Class::Method::Modifiers; # ... declare columns ... __PACKAGE__->has_many('group_servers', 'Your::Schema::GroupServer', 'group_id'); __PACKAGE__->many_to_many('servers', 'group_servers', 'server'); # if the server group is a "super group", then return all servers # otherwise return only servers that belongs to the given group around 'servers' => sub { my $orig = shift; my $self = shift; return $self->$orig(@_) unless $self->is_super_group; return $self->result_source->schema->resultset('Server')->all; };
If you just want to override the original method, and don't care about the data from the original accessor, then you have two options. Either use Method::Signatures::Simple that does most of the work for you, or do it the "dirty way".
Method::Signatures::Simple way:
package Your::Schema::Group; use Method::Signatures::Simple; # ... declare columns ... __PACKAGE__->has_many('group_servers', 'Your::Schema::GroupServer', 'group_id'); __PACKAGE__->many_to_many('servers', 'group_servers', 'server'); # The method keyword automatically injects the annoying my $self = shift; for you. method servers { return $self->result_source->schema->resultset('Server')->search({ ... }); }
The dirty way:
package Your::Schema::Group; use Sub::Name; # ... declare columns ... __PACKAGE__->has_many('group_servers', 'Your::Schema::GroupServer', 'group_id'); __PACKAGE__->many_to_many('servers', 'group_servers', 'server'); *servers = subname servers => sub { my $self = shift; return $self->result_source->schema->resultset('Server')->search({ ... }); };
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 DBD::Pg is compiled with a default port of 5432.
You can change the port setting in "postgresql.conf".
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>.
Check the list of additional DBIC resources.
This module is free software copyright by the DBIx::Class (DBIC) authors. You can redistribute it and/or modify it under the same terms as the DBIx::Class library.
2018-01-29 | perl v5.34.0 |