Update Constraints

Update constraints are used to perform automatic database integrity checks whenever an object instance is inserted or updated. These same constraints may or may not be implemented within the database itself. Even in cases where the database enforces these constraints it is a good idea to define these as part of the object so that constraint violations are handled in a user-friendly way with appropriate messages to inform the user of any constraint issues that they need to correct. Here is an example of some typical update constraints.

Let's review the various columns defined in the Update Constraints grid:

Constraint Schema

This should be used if the tables involved in the constraint are defined in a schema that differs from that of the primary table in the db_object.

Constraint Table

Enter the name of the table involved in the constraint.

Constraint Desc

This is used to give the constraint file a name to be used in messages. If this value begins with : it will be treated as a pointer to a translation value. For example, :language would cause a lookup to be performed for field language in the translation class specified for the object. If no translation class is indicated, the name of the db_object class will be used as the translation class name. You can also pass the translation class name in the description reference, for example, :table_names->language will cause the field to be looked up in the table_names translation class.

Constraint Key

Indicate the name of the foreign key within the primary object table that is involved in the constraint.

Lookup Columns

In addition to just checking the constraint value, it is possible to lookup additional columns from the constraint file.  For example, the language table includes a column called name to describe the language code. We might want to copy this name value to a field within the db_object. Suppose we create a derived column called language_name, you can specify language_name=name in the Lookup Columns. This will cause the name field to be included in the select statement when the language code is looked up and the resulting value will be copied to the language_name field in the object. If these field names were the same we could simply enter the field name without the equation.

My Constrained Column

Enter the column name within the object that corresponds to the foreign key to be checked.

Check Empty

Select this option if the lookup is to be performed even if there is no value in the foreign key. You should normally check this option if the foreign key is a required field.

Delete Constraints

Delete constraints are fired whenever you delete an instance of the db_object. This is used to ensure that the primary table row that is being deleted is not referenced as a foreign key of another object. For example, consider the following delete constraint:

This is used to check the Inventory table prior to deleting a film to make sure that the film is not referenced as inventory. If the film is references, the delete operation would not be allowed to complete since doing so would allow inventory rows to contain "broken links" to films that do not exist. Generally speaking, there should be a delete constraint whenever there is an update constraint. That is, since the inventory object should have an update constraint to ensure that only pre-defined films can be added to inventory by the same token we want to make sure that the film is not deleted later having been added to inventory.

Custom Code

Just like other classes that are generated by the php_class model can have custom code, so too can the generated db_object classes. Custom code can be used to override or supplement the get and set methods of all of the properties. Also, there are a number of optional functions that will be called at various points during the handling of an object if the functions exist. Click on the Insert Example Functions button to see some sample functions that can be coded.