[Dbix-class] Versioned Cluelessness

[luke saunders]

On Tue, Jul 8, 2008 at 1:36 PM, Christopher H. Laco <claco at chrislaco.com> 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.