Podius::Persistence::Media::FileBased - File-based persistence layer
# This example is not up to date and will not work
use Podius::Persistence::Media::FileBased;
$data_root_dir = '/usr/local/project/data';
$pm = new Podius::Persistence::Media::FileBased($data_root_dir);
$pm->insert(
'students',
[1, 2],
[{ name => 'Tom', age => '22' }, { name => 'Bob', age => '34' }]
);
my $first_student_name = $pm->retrieve('students', [1])->[0]->{name};
$pm->delete('students', [1]);
This package implements File Based Persistence Media for Podius Persistence Layer.
Table inheritance and single level transactions are supported.
Data is stored in files. Each file is named ``<key>.dat'' and placed in directory named ``table/<table>''. The directories are in the data base directory, which is specified in the constructor.
the Podius::Persistence::Media manpage, the File::Operations manpage, the Exception manpage, the Debug manpage, the Podius::Exceptions manpage.
submint method
or aborted by rollback method.
begin method.
All changes done during transaction to Persistence Media are commited.
begin method.
All changes done during transaction to Persistence Media are restored.
* table - name of table to insert data into. If table is ARRAY ref - the last name in the array is taken as table name and all rest are taken as supertable names and links in supertables to table instance are created.
* keys - array ref of row-keys to insert data into
* revisions - array of row revisions
* complex_rows - array of elements, each representing data of one row to save. Some of the row data will be saved in specified additional tables, instead of the main table. One complex_row is an array of the form:
[
[ [ field, ftype, value ]* ],
[ add_table, [ [ kfield, kvalue ]* ],
[ [ rfield, rvalue ]* ], [ [ lfield, [ lvalue* ] ]* ] ]*
]
* table - name of table to update data in
* keys - array ref of row-keys to insert data into
* revisions - array of row revisions
* complex_rows - array of elements, each representing data of one row to save. Some of the row data will be saved in specified additional tables, instead of the main table. One complex_row is an array of the form:
[
[ [ unmodified_field* ], [ unmodified_add_table_property* ] ],
[ [ field, ftype, value ]* ],
[ add_table, [ [ kfield, kvalue ]* ],
[ [ rfield, rvalue ]* ], [ [ lfield, [ lvalue* ] ]* ] ]*
]
* table - name of super table to look at * keys - array ref of row-keys to look at
* table - name of table to query
* keys - array ref of row-keys to query
* out_of_tx - optional boolean flag, work outside of the transaction
* table - name of real table to retrieve data from
* table_data - array of the form:
[
[ [ field, ftype ]* ],
[ add_table, [ ifield, [ cfield, cvalue ]* ],
[ rfield* ], [ lfield* ] ]*
]
* keys - array ref of row-keys to retrieve data from
* out_of_tx - optional boolean flag, work outside of the transaction
[
[ value* ],
[ [ rvalue* ], [ [ lvalue* ]* ] ]*
]
If any table key does not exist, Exception::Podius::NoTableKeyError is thrown.
* table - name of table to delete from. If table is ARRAY ref - the last name in the array is taken as table name and all rest are taken as supertable names and links in supertables to table instance are deleted.
* table_data - array of the form:
[
[ add_table, [ ifield, [ cfield, cvalue ]* ] ]*
]
* keys - array ref of row-keys to delete
update changes done to rows pointed by keys.
Calling this method outside a transaction should have no effect.
delete method.
update to determine conflicts.
Returns a subset of keys for which the revision (timestamp) was changed.
* table - name of table to delete from. * keys - array ref of row-keys to query. * revisions - array ref of original revisions to check against.
keys).
The exception must be thrown if there is still any data in the given table and all subtables.
* table - name of table to reset high key for * optional value of the high key to set (default: -1). Not implemented.
low_key_limit (1000).
When first time unique key is requested for given table, high key part is read,
incremented and stored back. This high key part is used for assigning first
low_key_limit new keys of given table, after that new high key is evaluated.
Resulting key is evaluated by this formula: high_key * low_key_limit + low_key.
* table - name of table to get unique key for * concrete_only - optional flag