luke saunders wrote:
On Tue, Jul 8, 2008 at 2:31 PM, Christopher H. Laco <[EMAIL PROTECTED]> wrote:luke saunders wrote: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.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?
Honestly? dbicadmin on steroids. dbicadmin --init MySchema dbicadmin --deploy MySchema dsn dbicadmin --upgrade MySchema dsn dbicadmin --ddl MySchema dirAnything 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.
-=Chris
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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]
