The db_object_child model works in conjunction with the db_object model. Before reviewing this help you should first make sure you are familiar with the basics of defining a db_object. As explained in the db_object help, in addition to a primary file, a db_object may be related to any number of secondary (dependent) files. Each of these secondary files is managed by a class generated using the db_object_child model.
Many of the inputs for the db_object_child model are similar to those used by the db_object model so in this help we don't go into details on these common inputs. Instead, the focus of this help will be to describe the additional inputs that are specific to the db_object_child model.
Specification Fields Specific to db_object_child components
The collection name is used in error messages that refer to the collection of db_object rows managed by the db_object_child class. If you wish to translate this collection name into multiple languages it should be preceded by colon (:). The colon should be followed by the name of a field within a translation class. If you have not specified a translation class, this defaults to the name of the class itself. You can also override the class by using the format :translation_class->variable.
When this feature is checked, multiple table rows will be inserted using a single SQL insert statement. While this is more efficient than doing multiple inserts it could be problematic to use this feature. The main drawback of choosing this option is that PDO is not capable of returning all of the auto-generated keys created during a combined insert statement. Therefore, the db_object must assume that these auto-generated keys are sequential. While this is generally the case, it is not guaranteed. This really only matters in situations where the user decides to perform an update immediately after performing the insert. In such a case, and if the auto-generated keys were not sequential, an SQL error might occur when the user performs the update.
In summary, this option should be chosen in situations where high performance is important or in cases where users are unlikely to perform an update on an object that was just inserted.
Also note that the database must support the ability to insert multiple database rows in one statement. This is indicated using the combine_inserts value set by the database adaptor class. The Combine Insert value set in the object parameter will be overruled in cases where the database does not support this feature.
Select this option if the db_object_child field references are to be translated using a translation class. This is important for multi-lingual applications.
Defining Key Fields
When defining the columns to be used to link the db_object_child table to the primary table it is necessary to specify all of the columns that make up this key. In most cases, the secondary file will reference two key fields:
Consider the following portion of the db_object_child definition for film_actor:
Notice that the film_id includes the DB Column Parms primary:1 to link this column to the film_id of the film table. The actor_id includes primary:2, this is necessary to ensure that the combined key film_id + actor_id is unique.
Further notice that the first_name and last_name fields are indicated with a DB Data Type of "derived". This means that these fields are not actually on the film_actor table but are derived from other sources. If we refer to the update constraint, we can see that these values will automatically be looked up during the process of executing this constrain check. These additional lookups also take place whenever a db_object is displayed.
Finally, make note of the Auto Assign Field for last_update. This will cause this field to be automatically assigned whenever there is an update or insert of the film_actor record.