Developing With Style

10 Responses to “CakePHP DB Migrations v4.0 is now Stable”

1. Funky Weasel
   October 10th, 2008 at 2:30 pm

   

   I noticed that running the new stable version throws: “Notice: Uninitialized string offset:” for lines 839,844,849,855, three times in the same sequence on an existing YAML script.

   Also - I’ve had trouble trying to set default values of fields - currently I can either have fields default to NULL or 1, the latter with:

   UP:
create_table:
requests:
some_text:
- not_null
some_flag:
type: boolean
- default: 0

   Omitting the dash before ‘default’ causes no default to be set. The only way I have found round this so far is to explicity define a field in a migration script using an ‘alter table’ statement.

2. Joel
   October 16th, 2008 at 12:48 am

   

   Please open up a ticket at http://code.google.com/p/cakephp-migrations/issues/list about the first issue, and be sure to include the YAML you are running.

   As for the second issue, a better way to write your migrations is as follows:

   
UP:
create_table:
requests:
some_text: not_null
some_flag: bool


3. Antoine
   October 21st, 2008 at 7:12 pm

   

   Hi,

   Just wondering, are you still maintaining your Fixtures project ? Found a little bug on my side.

   Had to change on line #178

   $data = Spyc::YAMLDump($this->_parsePhp($file));

   to :

   $data = Spyc::YAMLLoad($this->_parsePhp($file));

4. Joel
   October 22nd, 2008 at 12:48 pm

   

   Yes I am, because I use it. Think I fixed that in 4.0 stable.

5. Antoine
   October 24th, 2008 at 2:09 pm

   

   I got this error from the stable version downloaded on monday from Google Code.

   Thanks for this great shell, really really enjoying it. No more mysql dump importations.

6. Joel
   October 26th, 2008 at 11:01 am

   

   Please go ahead and open up a ticket. Thx.

7. Daniel Vecchiato
   October 29th, 2008 at 8:41 am

   

   great job Joel!
   I’ll test it out!
   Yammy!

   ;o)

   Dan

8. Alan Whitney
   October 29th, 2008 at 2:42 pm

   

   This looks very good. I tried it out a bit and I have a question, does it work with UUID’s instead of int primary keys.

9. Alan Whitney
   October 29th, 2008 at 2:49 pm

   

   My bad, I see yes it is in version 4

10. chuck
    February 12th, 2009 at 9:51 pm

    

    Hi Joel… I’m having some trouble writing migrations that add multiple columns to a table. If I stick to just the plain field_name: type form I’m ok, but once I start trying to do things like:

    add_field:
    some_table:
    new_field:
    type: some_type
    default: some_value
    other_new_field:
    type: some_type
    default: some_value

    or, alternatively, attempt it in separate add_field blocks:

    add_field:
    some_table:
    new_field:
    type: some_type
    default: some_value
    add_field:
    some_table:
    other_new_field:
    type: some_type
    default: some_value

    Strange things go on… either I get errors, or I don’t get all the new fields created (typically only the last one).

    This works OK though:

    add_field:
    some_table:
    field: some_type
    other_field: some_type

    Also, I want to complain a little about how when a “duplicate column” or “check that column exists” error occurs during a migration like this, it interrupts the whole migration and leaves some columns created and others not, causing any attempt to migrate that version up or down to bomb out similarly until you go into the db and manually add/remove columns to get rid of the errors.

    I understand that you can’t use alter table inside transactions (http://bugs.mysql.com/bug.php?id=28727) but you could at least have it go on and try the rest of the columns instead of leaving the migration half-done… then at least it would be possible to just migrate down, make any needed changes to the migration, and migrate back up again and have the database in a non-halfway-through-a-migration state.