[Dbix-class] Versioned Cluelessness

[Christopher H. Laco]

luke saunders wrote:
> 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.co=
m>
>>> 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=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 j=
ust
>> 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 upgr=
ade
>> 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 scr=
ipts
>> 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.
> =

> What do you propose?

Honestly?

dbicadmin on steroids.

dbicadmin --init MySchema
dbicadmin --deploy MySchema dsn
dbicadmin --upgrade MySchema dsn
dbicadmin --ddl MySchema dir

Anything to not have to write the age old generate.pl that does =

create_ddl_dir for new versions and deploy() and upgrade()...

If I were going for broke (which is entirely the Catalyst lists problem =

from here down):

catalyst.pl MyApp  (actually creates _schema.pl)
script/*schema.pl --init [MyApp::Schema]
script/*schema.pl --deploy [MyApp::Schema] [dsn_or_from_config]
script/*schema.pl --upgrade ...

Yes, there are more than one ORM for Catalyst. But DBIC is pushed as the =

defato standard, so what not make the mundane tasks as easyt as possible =

for those who want to use them.

Like I said, grains of salt born out of frustration of doing the same =

things over and over somewhat manually when other frameworks have these =

things already glued up to make the new users life easier. I don't hate =

Perl, Catalyst, or DBIC nor do I plan on leaving them anytime in the =

future. Just now that I've changed my perspective, I see many pointy =

corners.

Maybe when I'm done with the MVC Marathon train I can start spending =

some time working on round off some of those pointy corners.

-=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/66=
df2527/signature-0001.pgp