There's some debugging code somewhere in the DBIx::Class::DeploymentHandler dependency chain. We've looked and can't find it :( A case of beer at the next YAPC we meet at to whoever can figure it out.

Although if you see this, there's nothing wrong. The command will work as in the documentation. The only issue is that if there's a lot of debugging scroll by, you might need to page up in your terminal to catch any real error messages.

UPDATE: 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 doesn't play so nice with the way the YAML serializer works, since it does try hard to serialize objects.

A possible fix is to change SQLT::Parser::DBIx::Class so that it doesn't try to serialize that object. I think this could be a good fix since I don't think we can properly de serialize a DBI connection reliably.

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 I've 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). I've decided I'd rather not continue to spend my limited time dealing with dependency and installation management tools, when there's 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 understands.

If a better option with equal or greater maturity and community acceptance emerges, I'll 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 I'm not likely to accept patches that include significant changes to the way I'm using Dist::Zilla, including using plugins to weave pod, automagically guess dependencies and generate tests. I'd prefer to stick to the most simple and standard Perl practices for building and installing code for the present.

Having the database sandboxes automatically created in the share directory is a nice feature, but can clutter your repository history. You really don't 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

share/musicbase-schema/*
share/musicbase-schema.db

Other source control systems have similiar approaches (recipies welcome for sharing).

Its been reported that the developer database sandboxing feature doens't work properly when using AppArmor. I guess AppArmor considers this a security violation. Currently I don't have a reported workaround other than to just disable AppArmor, which for developer level machines may or may not be a problem.

Here's some symptoms of this problem, if you think you may be having it:

You didn't 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 can't 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 yourself:

Not everyone loves using an ORM. Personally I've 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 don't want to, or can not convince your fellow programers (yet :) ), here's one way to still use this migrations and fixtures system. Strictly speaking, we are stilling using DBIx::Class behind the scenes, just you don't have to know about it or use it.

You'd 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 you'll even be able to convince people to try out DBIx::Class!

You don't 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:

In this case let's say "dbi:mysql:database=myapp;host=10.0.88.98;port=3306" is a database that you've 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!

I don't know enough about Postgresql to know if the above settings are good, but they work for my testing. Corrections very welcome! Ideally I'd try to find a way to offer a patch to Test::postgresql, although this seems to be limited to people using Macs.