If you are generating any table that has a TIMESTAMP column, then Qcodo will automatically generate the functionality to perform Optimistic Locking for that object. In this example, the person_with_lock table is defined with a TIMESTAMP column so that we can demonstrate Optimistic Locking.

Optimistic Locking is the loosest form of row- or object-level locking that, in general, works best for database-driven web-based applications. In short, everyone is always allowed to read any row/object. However, on save, you are only allowed to save if your object is considered "fresh". Once your object is "stale", then you locked out from being able to save that stale object. (Note that this is sometimes also called a "mid-air collision".)

Programatically, this is done via TIMESTAMP columns. Remember that TIMESTAMP columns are updated by the database on every UPDATE.

So whenever you Load an object, you also get the latest TIMESTAMP information. On Save, the TIMESTAMP in your object will be checked against the TIMESTAMP in the database. If they match, then the framework knows your data is still fresh, and it will allow the Save. If they do not match, then it is safe to say that the data in the object is now stale, and Qcodo will throw an Optimistic Locking Exception.

Note that the Optimistic Locking constraint can be overridden at any time by simply passing in the optional $blnForceUpdate as true when calling Save.