zen of coding

CakePHP 1.3 helps with team-based development workflow…

I do have to say that in 1.2 some of the features described here are available as well, however CakePHP 1.3 takes it slightly to the next level to make team-based development even easier… With SVN or Git it is already easy enough to make team-based development readily accessible, that being said DB (schema and data) management during development process has always been a little bit painful.

Without too much dwelling let’s consider the following scenario. We have our favorite developers Joe and Bob.
(By the way, we are not going to cover any specific version control system here).

Bob starts up the project.
1. He creates the relevant Database with tables, adds a few models, controllers, actions, views.
2. He writes some code and populates the DB in the process with some dummy data.

So far, this should be familiar to most. Generally speaking, once Bob is done with the initial logical point of setup, he would commit all his work into some version control system.

Here’s where the pain of the past came into play…

While Joe can easily grab the application files, which are needed for the project, he is missing the DB structure and some data to continue working on the project.
Since early versions of CakePHP we’ve had a few built-in and third-party tools to help with that process, but they were lacking something… in one way or another. Not to say they didn’t get the job done, just the overall package wasn’t quite there.

Let’s see what to do in cake 1.3..

Bob fires up the command line and…

#cake schema generate

… which creates a php-based, cake-like schema.php file, which holds the information about the table structure.

Next, Bob types…

#cake bake fixture all -records -count 15

(Thanks Mark Story!)

This will bake all fixtures based on the current DB structure… and populate them with maximum of 15 records, which are currently in the database tables.
Fixtures are “nice little things”, but as far as we are concerned here, they simply hold our test data, so that Joe can have easy access to it.

OK, now that Bob was nice enough to do all of the above. He can happily commit all of the application code (including our newly baked schema and fixtures).

Moving on, at this point Joe is ready to get started on the project. He checks out the initial code from the version control repository.

Once the code is on his local development machine, Joe runs:

#cake schema create

Which, as you might have guessed, crates all the tables based on the schema developed and committed by Bob.
(It goes without saying that appropriate CakePHP and ultimately database configuration should already be in place on Joe’s development box).

Now that the tables are created Joe can begin his work, and while it is important to remember the “empty state” of an application, more often than not, some data is needed to get things rolling.

Well, all Joe needs to do at this point is:

#cake fixtures

Which, loads all the data from the fixtures into the newly created tables in Joe’s local database. Nice, eh?
At this point both development environments are fully in-sync and the progress can continue.
The above feature is currently in development and will not be available (or might change) depending on when you are reading this post.

A few things to note…

  1. I rarely find it useful to attempt to alter my schema. If the latest check-in has the required data and updated schema, I can safely drop all the tables, recreate them and insert new data
  2. To address the point above, all of my schema files are in the version control system, so if for whatever reason I need to go back, I simply check out the required revision and rebuild the schema (and add data if needed).
  3. This process can be followed back and forth for as many iterations as necessary.
  4. Human connection is necessary. If there is conflict in the code or schema… check with your fellow developer Bob or Joe and come to an agreement over a beer.
  • Thanks for sharing that! I had no idea this was possible, and had been manually keeping an SQL schema file. I can confirm that in 1.2, “cake schema generate” works, as does creating or updating the database from the schema.php file, though the command is “cake schema run create” and “cake schema run update”. I couldn’t seem to get fixtures working in 1.2 though.

  • @nickf

    Glad it was helpful… and you are correct fixture baking is a new feature of 1.3.
    (Perhaps I’ll add a little blurb for those still using 1.2).

  • Pingback: Twitter Trackbacks for CakePHP 1.3 helps with team-based development workflow… « nuts and bolts of cakephp [teknoid.wordpress.com] on Topsy.com()

  • Martin Westin

    That fixture generating script a great new feature. Creating fixtures is by far the most boring part of making unit tests and to have that done away with will be very nice.

    I would also like to point out my pet-problem which is rarely mentioned in relation to database migrations. Anyone working on an app not build for an English/American audience should be very wary about using the schema shell… or any schema managing application they end up using… most of them miss vital details that can mess up your data or sql operations.

  • asd

    it’s nice but little bit pointless from syncing dev environments cause it can (and needs to) be more abstract.

    So I just suggest you to spend those 10 minutes setting up a capistrano config file which syncs your environments (or creates different versions of them as you need)

  • dogmatic69

    nice article, if it changes before going stable im sure it will be for the better. cant wait for cakephp 1.3

    gonna check out this fixture bakeing

  • @Martin Westin

    What specific details are being missed? I think it’s important to point those out…


    Sorry, but I have to disagree. At some point all developers involved in a project should be working on the same code-base, which should also imply they are using the same schema (and likely test data). The environments can certainly differ in some ways and they may not always be in-sync, but the goal here was to point out the new features in cake, rather than to describe capistrano :)


    There’s nothing stopping you from jumping into 1.3 now ;)

  • Martin Westin


    It is a bit longwinded to explain in comment-from… sorry.

    If you specify collations and charsets in you database, table or fields… only some of these will make it across the migration.

    Say your local MySQL is latin by default and you set utf8 on your database and tables. Then you specify Swedish collation on the field users.name so that it finds and sorts correctly on Swedish names. Then you migrate to a server and your schema ends up without that field collation… all your finds of users will now result in strange errors. finding by name may find the wrong user, listing all will probably list names in the wrong order.

    collations (3 line crash course) know the alphabet of a language:
    english: a b c .. x y z
    swedish a b c .. x y z å ä ö (that is the only diference)
    sorting or searching Swedish text should treat those three extra a’s not as a’s but as their own characters and sorted at the end of the alphabet.

    If the server has completely different defaults you can end up with similar problems and data may become garbled when you import it.

    I believe Cake ignores all which is actually better than the tools keeping half of them and ignoring the rest. Ignoring all will “force” the database and all tables and fields to confirm to the defaults of the server installation…. which is at least consistent. Imagine having half your tables in latin and half in utf8 by accident.

    The problem is further complicated by how MySQL handles changes to these things. Changing the table will in some circumstances (have no details on when) cause MySQL to enter values for each field so they won’t be affected unless you also change them specifically. So, migrating a table-lever change can cause all sorts of problems when that change partially affects individual fields.

    In short. It is a big mess unless you are careful. :)

    I am a MySQL guy (patriotic Swede?). This may be something that does not affect other rdbms or even some other engines used by MySQL… I mostly use the default MyISAM. I have only investigated this thoroughly once… when I migrated a live application and all hell broke loose for 400’000 user accounts :) Now I am careful and border-line paranoid about database schemas.

  • @Martin Westin

    I run into collation problems every day :)

    However, here’s a bit of good news:
    ‘street_2’ => array(‘type’ => ‘string’, ‘null’ => false, ‘default’ => NULL, ‘collate’ => ‘utf8_unicode_ci’, ‘charset’ => ‘utf8’),
    ‘tableParameters’ => array(‘charset’ => ‘utf8’, ‘collate’ => ‘utf8_unicode_ci’, ‘engine’ => ‘InnoDB’)

    This is copy/pasted from 1.3 schema file.

  • Hey teknoid thanks for posting this, fixtures were definitely a pain point in 1.2. Hopefully the changes in 1.3 make things easier in that area. Collation and charset are in the process of being supported for the primary database drivers in 1.3 as best they can. Hopefully we can make encoding mixups a thing of the past.

  • @Mark Story

    My part is easy… thanks for making all this happen ;)

  • Martin Westin

    That looks like great news… so long as the support is complete and not 90% as with many migration scripts and desktop apps. I’ll remember to test it when I find some time to try out 1.3

  • Yes it’s very useful, but in my job we use procedures sometimes and this unfortunetely would not help :(

  • @dezpo

    Sad procedures :(

  • Pingback: CakePHP : signets remarquables du 28/10/2009 au 30/10/2009 | Cherry on the...()

  • I’ve experienced problems with Database Views with schema synchronization. I haven’t test 1.3 so far but for sure this wasn’t working properly in 1.2

  • @Nik Chankov

    well, the most important thing was not in 1.2 — fixture baking. also schema generation has improved quite a bit.

  • Running

    cake fixtures

    Does not seem to work in the latest releases of 1.3 straight from the repository. I swear it worked at one point though. Anything change that we should know about?

  • @Jose Diaz-Gonzalez

    It’s an external shell, which I’ve been meaning to modify and contribute back to the core.
    Time, of course, is not on my side…

    You should be able to grab a copy at debuggable.com

  • Played with it for the first time tonight. By adding the “-plugin PluginName” you can create schemas based on the models in your plugins. This makes them even more portable. Sweet!

%d bloggers like this: