[Dbix-class] Versioned Cluelessness

[luke saunders]

On Wed, Jul 9, 2008 at 1:22 AM, Ash Berlin <ash_cpan at firemirror.com> wrote:
>
> On 9 Jul 2008, at 01:13, luke saunders wrote:
>
>> On Wed, Jul 9, 2008 at 12:54 AM, Christopher Laco <claco at chrislaco.com>
>> wrote:
>>>
>>> Christopher Laco wrote:
>>>>
>>>> luke saunders wrote:
>>>>>>>>
>>>>>>>> NOTE: Since SQL::Translator 0.09000 it is better to just run all
>>>>>>>> statmets
>>>>>>>> in the order given, since the SQL produced is of better quality.
>>>>>>
>>>>>> Hmmm yeah, I briefly toyed with idea of removing that regexp check and
>>>>>> just
>>>>>> running stmts the order that the appear in the SQL file, probably for
>>>>>> the
>>>>>> exact reason you are complaining about.
>>>>>>
>>>>>> Is there anyone out there that is *using* this feature? If you don't
>>>>>> speak
>>>>>> up soon I'll remove it.
>>>>>
>>>>> The version in svn will run the statements in the order they are in
>>>>> the SQL file, but the method still exists if people want to override
>>>>> it. I only changed this last week so it's not in a dev release yet.
>>>>>
>>>>>
>>>>
>>>> Just for the sake of asking..
>>>>
>>>> If I'm on version 1, and upgrade() is moving to version 3... will it try
>>>> to run the 1-2 file, then the 2-3 file... or will is always assume a
>>>> single
>>>> 1-3 file?
>>>
>>> IS this an SQLite-ifact, or somethig wrong between the default AutoCommit
>>> and the diff files?
>>>
>>>> claco at mbp ~/mvc-marathon/catalyst/BurningPlate $ script/*upgrade.pl
>>>> dbi:SQLite:burning_plate.db
>>>> Versions out of sync. This is 2, your database contains version 1,
>>>> please
>>>> call upgrade on your Schema.
>>>> DBIx::Class::Schema::Versioned::upgrade(): DBI Exception:
>>>> DBD::SQLite::db
>>>> do failed: cannot start a transaction within a transaction(1) at
>>>> dbdimp.c
>>>> line 402 [for Statement "BEGIN"]
>>>
>>> The diff files have tings wrapped in BEGIN/COMMIT, and I assume this on
>>> top
>>> of the default transaction is the issue.
>>
>> Yeah, I've just added a change to Versioned.pm which should strip
>> those BEGIN/COMMIT statements out. Ideally we'd have SQLT not generate
>> them in the first place but I don't think that's going to happen
>> before we release this. Anyway, if you could test the change that
>> would be good.
>
> Um no. SQLT *should* generate them, since almost every proper RBMS does
> transactional DDL (hell, even sqlite does it)

Right, but we don't want it to because we wrap it in our own transaction.