[Dbix-class] Versioned Cluelessness

[luke saunders]

On Tue, Jul 8, 2008 at 2:31 PM, Christopher H. Laco <claco at chrislaco.com> wrote:
> luke saunders wrote:
>>
>> 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.
>
> If I'm asking to upgrade() a database that's not empty, would it really
> already have a different schema then the version I'm going to?

The assumption at the moment is that the version in the db is the same
as the current schema version, so it's your responsibility to get it
there before initialising the dbic versioning. The docs don't make
that clear, and the fact that ->upgrade doubles up as the initialise
method doesn't help, but that's fixable.

> If it did, why not just insist on a -unversioned-1.sql file that handled the
> initial upgrade from no versioning tables to versioned.

it's better to set the version in MyApp::Schema to 0.000, then create
a DDL of that current schema in your sql directory called
MyApp-Schema-0.000-MySQL.sql (or PostgreSQL or whatever), then
initialise your versioning table by calling upgrade. At which point
your db is at version 0.000, that's what it says in MyApp::Schema and
you have a DDL for it in your sql directory. At which point you can
make changes to your DBIC schema, increment the version in
MyApp::Schema and create the new DDL and the diff from 0.000 using
create_ddl_dir. Then running upgrade will run the diff from old to
new.

>>> 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.
>
>
> While I understand the position about upgrade from the Perl perspective and
> not wanting to trash an existing database, from the new user it should just
> work perspective: it doesn't. If I create a new schema, and deploy, then I
> upgrade() to version 2, it's not unreasonable to expect that the version
> 1->2 sql script should be run. After all, I just asked it to upgrade the
> schema, yet it did not, and it didn't even try or complain that it doesn't
> want to.

It is entirely unreasonable to expect it to magically know about version 1.

There needs to be more docs on getting started with versioning, then
people wouldn't have these expectations.

> In the end, setting up a new schema and versioning it seems to be harder
> than it should be. When I ask it to upgrade a schema, it should. An upgrade
> could just as well trash the db as upgrading a db with no version table at
> all. Don't get me started about the fact that I have to write my own scripts
> to to upgrade/deploy rather than dbicadmin knowing --op=deploy or
> --op=upgrade.
>
> No: perl -MMySchema -e 'MySchema->connect(...)->deploy' does not count as
> user friendly.

What do you propose?

> Take it with a grain of salt. I'm working on this:
> http://today.icantfocus.com/blog/mvc-marathon/ and I'm going to end up
> pissing off a lot of people over the next few months with what I say. So
> far, even after doing Perl/DBIC/Cat as my native language, it ends up
> pissing me off more than Rails/CakePHP/Django does. It's not new user
> friendly sometimes. It's not intuitive sometimes with things like this
> compared to others. And what distresses me the most is the Perl attitude
> about everything: just because TIMTOWTDI doesn't mean you have to refuse to
> pick a one way to do it and make the tools a lot easier for that one way.
>
> But I digress....
>
> -=Chris
>
>