Manual Reference Pages - DBIX::CLASS::MIGRATION::FAQ (3)
DBIx::Class::Migration::FAQ - Answers to Frequently Asked Questions
When I run the commandline, I see a lot of debugging output
SV = IV(0x7fb4e24dc858) at 0x7fb4e24dc868
REFCNT = 1
FLAGS = (ROK,READONLY)
RV = 0x7fb4e0b0ddf8
SV = PVHV(0x7fb4e24c48a0) at 0x7fb4e0b0ddf8
REFCNT = 1
FLAGS = (OBJECT,SHAREKEYS)
STASH = 0x7fb4e2174a80 "DBI::db"
ARRAY = 0x0
KEYS = 0
FILL = 0
MAX = 7
RITER = -1
Theres some debugging code somewhere in the DBIx::Class::DeploymentHandler
dependency chain. Weve looked and cant find it :( A case of beer at the
next YAPC we meet at to whoever can figure it out.
Although if you see this, theres nothing wrong. The command will work as in
the documentation. The only issue is that if theres a lot of debugging scroll
by, you might need to page up in your terminal to catch any real error
<B>UPDATEB>: I recieved an email from a contributor who has code dived a bit
and possibly narrowed down the issue. I thought to report that stuff here.
When SQLT::Parser::DBIx::Class attempts to serialize schemas that are connected
it trys to serialize the connect object information. This doesnt play so nice
with the way the YAML serializer works, since it does try hard to serialize
<B>UPDATEB>: This may be fixed in recent updates to the DBIC ecosystem. If you
are seeing this try upgraded DBIC and SQLT and see if it goes away.
<B>UPDATEB>: You really should not be seeing this anymore, if you are, and youre
on the lastest DBIC and related, please let me know.
Contributing to the project is easy. First youd fork the project over at
Github (<https://github.com/jjn1056/DBIx-Class-Migration>), clone the repo
down to your work environment and install project dependencies:
dzil authordeps | cpanm
dzil listdeps | cpanm
You should first have a Modern Perl setup, including local::lib. If you
need help installing Perl and getting started, please take a look at the
Learning Perl website: <http://learn.perl.org/installing/>
I realize Dist::Zilla seems to invoke feelings on nearly religious vigor
(both for and against). After considering the options I felt using it, but
carefully constraining the use of plugins to the default set was a better
option than what Ive done on other projects, which is to have a custom wrapper
on top of Module::Install (you can peek at that if you want over here:
<https://github.com/jjn1056/Maker>). Ive decided Id rather not
continue to spend my limited time dealing with dependency and installation
management tools, when theres a rational solution that many people already
embrace available. The only other option is to continue to build and maintain
code for this purpose that nobody else uses, and possibly nobody else
If a better option with equal or greater maturity and community acceptance
emerges, Ill entertain changing.
If the requirement of typing cpanm Dist::Zilla and using the dzil command
line tool for a limited number of build jobs prevents you from contributing,
I think you are unreasonably stubborn.
If you do contribute to the project, please be aware that Im not likely to
accept patches that include significant changes to the way Im using
Dist::Zilla, including using plugins to weave pod, automagically guess
dependencies and generate tests. Id prefer to stick to the most simple and
standard Perl practices for building and installing code for the present.
I dont want my database sandbox files in my source control repository
Having the database sandboxes automatically created in the share directory
is a nice feature, but can clutter your repository history. You really dont
need that in the source control, since installing and controlling your database
is something each developer who checks out the project should do.
If you are using git you can modify your .gitignore. If you sandbox is
share/myapp-schema.db or (if you are using the mysql or postgresql sandboxes)
share/myapp-schema/ you can add these lines to your .gitignore
Other source control systems have similiar approaches (recipies welcome for
Whats the command to run migrations on an existing database?
dbic-migration -Ilib status \
--user msandbox \
Would be the general approach.
Error: Trouble creating a MySQL Sandbox when running AppArmor
Its been reported that the developer database sandboxing feature doenst
work properly when using AppArmor. I guess AppArmor considers this a
security violation. Currently I dont have a reported workaround other than
to just disable AppArmor, which for developer level machines may or may not
be a problem.
Heres some symptoms of this problem, if you think you may be having it:
In /var/log/syslog something like:
kernel: [18593519.090601] type=1503 audit(1281847667.413:22):
operation="inode_permission" requested_mask="::r" denied_mask="::r"
fsuid=0 name="/etc/mysql0/my.cnf" pid=4884 profile="/usr/sbin/mysqld"
If you need AppArmor, youll have to setup and install MySQL the old school
Error: Failed to find share dir for dist...
You didnt specify a custom --target_dir but forgot to make the /share
directory in your project application root.
By default we expect to find a /share directory in your primary project root
directory (contains your Makefile.PL or dist.ini, and the lib and t
directories for example) where we will create migrations. At this time we cant
automatically create this /share directory in the same way we can create all
the migration files and directory for you. You need to create that directory
Patches to fix this, or suggestions welcomed.
Can I use this even if I dont want to use DBIx::Class?
Not everyone loves using an ORM. Personally Ive found DBIx::Class to be
the only ORM that gets enough out of my way that I prefer it over plain SQL,
and I highly recommend you give it a go. However if you dont want to, or can
not convince your fellow programers (yet :) ), heres one way to still use this
migrations and fixtures system. Strictly speaking, we are stilling using
DBIx::Class behind the scenes, just you dont have to know about it or
You use a subclass of DBIx::Class::Schema::Loader in a namespace for your
use base DBIx::Class::Schema::Loader;
our $VERSION = 1;
Youd put that in lib/MyApp/Schema.pm along with your other application code.
then just use MyApp::Schema as is discussed in the documentation. This will
dynamically build a schema for you, as long as you set the schema arguments to
connect to your actual database. Then everytime someone changes the database
you just up the $VERSION and take it from there. Obviously this is a bit
more manual effort, but at least you can have the ability to populate to any
given version, manage fixtures, do some sane testing, etc. Maybe youll even
be able to convince people to try out DBIx::Class!
By the way, if you wanted, you can always dump the generated version of your
classes using make_schema (see make_schema in DBIx::Class::Migrations and
make_schema in DBIx::Class::Migrations::Script).
I am using MySQL and when the migration fails, it doesnt ROLLBACK
Thats because MySQL does not support transaction DDL. Even if you have a
transaction, MySQL will silently COMMIT when it bumps into some DDL.
I need to dump fixtures from a existing database
You dont always have the luxury of building a new database from the start.
For example, you may have an existing database that you want to start to
create migrations for. In this case you probably want to dump some data
directly from that existing database in order to create fixtures for testing
or for seeding a new database.
DBIx::Class::Migration will let you run the dump_all_sets and dump_named_sets
commands against an unversioned database. For example:
dbic-migration -Ilib -SMyApp::Schema dump_all_sets /
--username johnn /
In this case lets say dbi:mysql:database=myapp;host=10.0.88.98;port=3306 is
a database that youve been managing manually and it has some data that is useful
for creating your fixture sets.
When you run these commands against an unversioned database you will be warned
because we have no way of being sure what version of the fixture sets you should
be dumping. We will just assume that whatever the Schema version is, is correct.
This can of course lead to bad or undumpable fixtures should your Schema and the
unversioned DB not match properly. Buyer beware!
Error: is not a module name
Sorry this error is vague and I am working on a fix. You will get this if you
have failed to provide a schema_class, either by setting it with the -S or
-schema_class commandline option flag:
dbic-migration -Ilib -SMyApp::Schema
dbic-migration -Ilib --schema_class MyApp::Schema
or by exporting the %ENV:
Or, if you have a custom version of DBIx::Class::Migration::Script as
discussed in the tutorial, you are not providing a good schema_class value.
Error: Attribute (schema_class) does not pass the type constraint
You probably forgot to include your project lib directory in the Perl search
path. The easiest way to fix this is to use the I or lib command line:
dbic-migration -Ilib -SMyApp::Schema [command]
When using the Postgresql Sandbox, I get FATAL: could not create shared memory segment
There will be more like this:
FATAL: could not create shared memory segment: Cannot allocate memory
DETAIL: Failed system call was shmget(key=1, size=2138112, 03600).
HINT: This error usually means that PostgreSQLs request for a shared memory
segment exceeded available memory or swap space, or exceeded your kernels
SHMALL parameter. You can either reduce the request size or reconfigure
the kernel with larger SHMALL. To reduce the request size (currently 2138112
bytes), reduce PostgreSQLs shared memory usage, perhaps by reducing
shared_buffers or max_connections.
The solution is as presented. Since I prefer not to change my system settings
permanently, just add the following to a little bash script in my application
sudo sysctl -w kern.sysv.shmall=65536
sudo sysctl -w kern.sysv.shmmax=16777216
I dont know enough about Postgresql to know if the above settings are good,
but they work for my testing. Corrections very welcome! Ideally Id try to
find a way to offer a patch to Test::PostgreSQL, although this seems to be
limited to people using Macs.
How to Release
Heres the release steps I currently use, should I eventually find willing
You need to increment the version in dist.ini and in DBIx::Class::Migration
Prepare Changes file
Update the Changes file. It would be ideal to have been adding to this as
youve gone along, but you should double check.
Update Authors list
If there have been new contributors, be sure to give credit
Rebuild the README
pod2markdown < lib/DBIx/Class/Migration.pm > README.mkdn
This will make sure the README.mkdn file in the project root matches the most
Check your tests
AUTHOR_MODE=1 prove -lvr t
Update the repository
git add @stuff_to_add
git commit -m $message
Make the Distribution
Update the git version tag
I usually dont update and push the tag until we are on CPAN.
git tag $VERSION -m cpan release
git push --tags
See DBIx::Class::Migration for author information
COPYRIGHT & LICENSE
See DBIx::Class::Migration for copyright and license information
|perl v5.20.3 ||DBIX::CLASS::MIGRATION::FAQ (3) ||2015-03-24 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.