>> That's an interesting point of view. I tend to make my database changes >> directly with SQL and when I am ready regenerate the schema files from there. > > This makes for poor testability. Otherwise, when you have a schema > change, you either: > 1. Force everyone sharing the same developer instance to immediately > have to deal with your schema changes > 2. Force everyone who isn't sharing the same developer instance to > have to deal with it when they do a "git pull" > > Much better to have DBIx::Class::Schema::Versioned to just do the > right thing for you.
I guess I get away with this as I am usually the only developer on the application! But this is something I will look into as I want to learn how to do it this way. Actually if I go down this path, how would you deploy database functions (eg pl/pgsql) ? >> One other question, when you used your $schema object, where do you put your >> connection information, to avoid having it in every single test script? > > I generally have a test helper that creates a $schema object for me. > This helper would look in some configuration file that's specific for > tests and you can then control it from there. Configuration files are > amazing things. Ah, Test::DBIx::Class helps with this Thanks again Adam _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
