[Dbix-class] Versioned Cluelessness

[Christopher H. Laco]

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?

If it did, why not just insist on a -unversioned-1.sql file that handled =

the initial upgrade from no versioning tables to versioned.

>> Of course, running deply first, then upgrade just yields the
>> addition of the versioned tables, but no upgrade scripts get run (if I w=
as
>> now on $VERSION=3D2).
> =

> 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.

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=3Ddeploy or --op=3Dupgrade.

No: perl -MMySchema -e 'MySchema->connect(...)->deploy' does not count =

as user friendly.

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....

-=3DChris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20080708/c4=
d79cbc/signature.pgp