EntityModel::Storage - backend storage interface for EntityModel
version 0.102
See EntityModel.
See EntityModel for more details.
Register with EntityModel so that callbacks trigger when further definitions are loaded/processed.
The base storage engine doesn't provide any callbacks - but we define the method anyway so that we don't need to check for ->can.
Apply the given model.
Apply the given model to the storage layer.
This delegates most of the work to "apply_entity".
Reads the data for the given entity and returns hashref with the appropriate data.
Parameters:
entity - EntityModel::Entity
id - ID to read data from
Creates new entry for the given EntityModel::Entity.
data - actual data values
Stores data to the given entity and ID.
id - ID to store data to
Removes given ID from storage.
Find some entities that match the spec.
Returns the previous and next element for the given ID.
Returns previous element for the given ID.
Returns next element for the given ID.
Returns first and last IDs for the given entity.
Returns first active ID for the given entity.
Returns last active ID for the given entity.
Mark the start of a transaction.
Roll back a transaction.
Commit this transaction to storage - makes everything done within the transaction permanent (or at least to the level the storage class supports permanence).
Release the transaction on completion.
This module provides the abstract base class for all storage modules. Here's how to build your own.
"setup" will be called when this storage class is attached to the model via "add_storage" in EntityModel, and this will receive the $model as the first parameter along with any additional options. Typically this will include storage-specific connection information.
Each entity added to the model will be applied to the storage engine through "apply_entity". It is the responsibility of the storage engine to verify that it is able to handle the given entities and fields, either creating the underlying storage structure (database tables, etc.) or raising an error if this isn't appropriate.
Most of the work is handled by the following methods:
"read" - retrieves data from the backend storage engine for the given entity and ID
"create" - writes new data to storage for given entity, data and optional ID
"store" - updates an existing entry in storage for the given entity, data and ID
"remove" - deletes an existing entry from storage, takes entity and ID
Each of these applies to a single entity instance only. Since they operate on a callback basis, multiple operations can be aggregated if desired:
select * from storage where id in (x,y,z)
Two callbacks are required for each of the above operations:
on_complete - the operation completed successfully and the data is guaranteed to have been written to storage. The strength of this guarantee depends on the storage engine but it should be safe for calling code to assume that any further operations will not result in losing the data - for example, a database engine would commit the data before sending this event.
on_fail - the operation was not successful and storage has been rolled back to the previous state. This could be the case when trying to create an item with a pre-existing ID or possibly transaction deadlock, although in the latter case it would be preferable to attempt retry some reasonable number of times before signalling a failure.
Neither callback is mandatory - default behaviour if there is no on_fail is to die() on failure, and no-op if on_complete is not specified.
on_fail
on_complete
add_handler_for_event, clear_event_handlers, event_handlers, invoke_event, subscribe_to_event, unsubscribe_from_event
clone, dump, new, sap
Tom Molesworth <cpan@entitymodel.com>
Copyright Tom Molesworth 2008-2011. Licensed under the same terms as Perl itself.
To install EntityModel, copy and paste the appropriate command in to your terminal.
cpanm
cpanm EntityModel
CPAN shell
perl -MCPAN -e shell install EntityModel
For more information on module installation, please visit the detailed CPAN module installation guide.