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