[Dbix-class] Versioned Cluelessness

[Ash Berlin]

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)

-ash