The generated models
Although we have only created five tables, looking in the lib/model folder, and the subfolders of om/ and map/ reveals that there are a total of 25 files. The files that we are interested in are located in the lib/model and lib/model/om folders. The files generated in the lib/model/om folder contain all of the base classes, and the files in the lib/model folder contain the custom classes that extend the base classes.
You will also notice that for each class there is also a corresponding peer class. The peer classes are what we use to query the database, and are referred to as the Data Access Objects (DAOs). Within these classes, there are numerous methods created for us. The non-peer counterpart represents the rows of the table in the result set and provides us with methods to access the data in each row.
The custom classes are where we add our methods to query the database. It is important that we add all our code to the custom classes, and if need be extend the base classes functions here too. The reason for this is if a change is made to the schema when we use the Symfony task to rebuild the models, all of the base classes will be regenerated. The custom models remain untouched.
Populating the database
As mentioned above, throughout an application's development cycle, changes to the database will be inevitable sooner or later. This means that changes to your schema will result in the rebuilding of the models, forms, and filters as well as the deletion and recreation of the database tables. If you already have a pre-populated database, it makes no sense to manually re-enter all the data. Of course, you could create an SQL patch file, but Symfony helps to make this process less of a headache by a fixtures YAML file.
A fixtures file allows a developer to add test data, which is used to populate the database. On the command line, you can use a Symfony task that will insert this data for you. To insert the data, the models that we created earlier are used. This mimics the same process that we will use to retrieve and insert our own data.
As a part of the project creation process, a fixtures file—fixtures.yml—was generated in the data/fixtures folder and contains an example. Open this file, delete its content, and replace with our data as follows:
MilkShake:
m1:
name: Blueberry
calories: 200
image_url: blueberry.jpg
m2:
name: Chocolate Digestive
calories: 400
image_url: chocolate_digestive.jpg
m3:
name: Raspberry
calories: 250
image_url: raspberry.jpg
Flavor:
f1:
name: Banana
f2:
name: Strawberry
f3:
name: Cheesecake
f4:
name: Chocolate
MilkshakeFlavor:
mf1:
milkshake_id: m1
flavor_id: f15
mf2:
milkshake_id: m2
flavor_id: f10
mf3:
milkshake_id: m3
flavor_id: f13
mf4:
milkshake_id: m6
flavor_id: f1
mf5:
milkshake_id: m6
flavor_id: f2
StoreLocation: l1: address1: The Strand address2: postcode: wc2r we4 country: uk phone: +44 (0)208 789 9875 fax: +44 (0)208 789 9876
The structure of the file is pretty straightforward. The labels represent the classes of each of the tables. Looking at the StoreLocation label, we have a corresponding StoreLocation class that represents the store_locations table. The l1 key represents that record as a unique object, which allows us to reference if needed as we have done in the MilkshakesFlavor section. The final attributes are the attributes of the class that represent the table columns.
Now we have test data, and can use the Symfony task to insert it for us. Enter the following Symfony task in your terminal window:
$/home/timmy/workspace/milkshake>symfony propel:data-load
Now that we have a populated database, we can start the process of introducing the business logic to our site.
Note
It is important to note that the YAML syntax does not accept tabs, but only spaces. Also, correct indentation is required. Visit their web site at http://www.yaml.org/ to get a grips on YAML.
Your IDE should allow you to use spaces rather than a tab.