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…
- 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
- 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).
- This process can be followed back and forth for as many iterations as necessary.
- 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.
