As of version 1.4.beta1 phpPeanuts supports and uses database transactions. The standard actions automatically start a transaction before they retrieve data. After successfully updating they commit the transaction. If an error occurs, they rollback the transaction. The error may be an error message from stringconversion, validation or get..ErrorsMessages, or an error triggered that can be handled by an error handler. Fatal errors and exceptions are not handled*.
PhpPeanuts does not warn if a database engine does not support transactions and does not warn. Rollback will simply have no effect. This may leave your data in an inconsitent state.
PnhPeanuts' transaction integrity only spans the duration of an action. It is not cheched if the data has been changed while the user was editing it, waiting for the network or processing other then the action took place. To do that would require transactions that span span more then one request. That is incompatible with the way PHP handles database connections.
It is left to the application developer to choose a cross request locking strategy if he needs one, and implement it. You can added optimistic locking by giving every object a version number, include the version number in each Form that invokes actions and checking it to be unchanged in the database when the action is processed. However, this will only protect individual objects in relation to their data that was displayed at the point where the user started the action. The user may still base his actions on other data, that may be outdated at the time the user took his decision, or recursive delete may delete object the user did not get to see at all.
Redaction systems may go a step further and pesssimistically lock documents or sets of documents that are under review until released explicitly by the editor. Or like most wiki's, make versions of all their pages so that no data is lost whatever race condition occurs.
* Exceptions from Pdo should to be handled, please inform us if you find unhandled exceptions. |
