On Tue, Jul 8, 2008 at 1:36 PM, Christopher H. Laco <[EMAIL PROTECTED]> wrote: > luke saunders wrote: >> >> if the db isn't versioned then it's assumed that the database is >> already at the current version and all that happens is that the >> versioned table is created. i can see that this might be confusing so >> i'll beef out the docs later. >> >> it probably also makes sense for Schema::Versioned to overload deploy >> so that the versioned table is created after that runs, then if you're >> starting from scratch you can deploy initially then run upgrades after >> that. > > Yeah, the overloaded deploy would seem to close that gap between what > happens and what's expected. Having never used Versioned before, I > completely expected upgrade to deploy the entire schema since you're on > version undef.
That's fine if your database is empty but not if there is a preexisting database, which is why we'll just have to make it clear that you need to run deploy first in the former case. > Of course, running deply first, then upgrade just yields the > addition of the versioned tables, but no upgrade scripts get run (if I was > now on $VERSION=2). But what upgrade script would you expect to be run in this case? Versioned doesn't know what version you were on before because there was no versioned table. There is an option which allows a diff of the existing database and the current dbic schema to be generated for your reference when upgrading for the first time, but the resulting SQLT diff is a big mess of column changes caused by database defaults which aren't present in the DBIC schema, so it's not that useful. Although logically that should be what's run to 'upgrade' to the current version. _______________________________________________ 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/[EMAIL PROTECTED]
