name

Jifty SVK Model docs

SUMMARY

IMPLEMENTATION

Reading and writing from the data store

- Upon each mount, read everything, expiry-keyed by revnum - Build in-memory index for common accesses - Encourage ->begin and ->commit to take advantage of svk txns - Otherwise it's autocommit - svn:author is $ApplicationClass-$ApplicationUser

Implementation plan

Functionality

create objects

read objects

find objects

update objects

delete objects

API

- First step is a memory-only, svn-compatible layout backend store - Composed of alternate implementation of APIs of: - Jifty::Record - Jifty::Collection

Jifty::Record

Methods:

create

set

value (get)

delete

Jifty::Collection

next

items_array_ref

unlimit

search

This is a new API. It replaces Jifty::DBI::Record's "limit"

My $tasks = MyApp::Model::TaskCollection->new();

grep { $_->summary =~ 'foo'} grep { $_->owner

# Tasks with a summary matching 'patch' AND with patches (computed)

$tasks->with( summary => qr/patch/)->with( sub { $_->has_patches() } )

# Tasks with a summary matching 'patch' or with patches (computed)

$tasks->in( $tasks->with(summary => qr/patch), $tasks->with(sub {$_->has_patches}))

# Tasks with a summary that doesn't match 'patch' with patches $tasks->without( summary => qr/patch/)->with( sub { $_->has_patches() } )

Data storage format (In SVN)

- Subversion based object store, using headless YAML::Syck for now - Each object is a /UUID/ directory - Optionally encoded as /U/UUID/ or /U/UU/UUID/ etc - Each field is a /UUID/field_name file - If it has a jifty:class then it's going to be blessed into that - Type the object is encoded as the dirprop jifty:table - It's blessed into the "class" name defined in the jifty-table repository - Time of creation object is encoded as the dirprop jifty:created - A simple floating number of Time::HiRes::time() - The jifty:table themselves are but UUIDs of table-objects - Also stored in the data store - They are of the builtin table "Jifty::Model::Table" - "class" : [ "Perl::Land::Class" ] # Record Class - They are of the builtin table "Jifty::Model::Column" - "table" : the Table it's associated of - "name" : field name - "type" : jifty type-tag - ...other column info... - J::M::T and J::M::C (recursively defined) are always present in any data store - Consequently, jifty model --create must do a uuidgen when backending SVN.

Runtime storage format (in memory)

- In-memory structure looks like this:
    {$type-uuid}
        [objects-sorted-by-timestamp]
            - inside-out objects comprised of a single UUID as payload
    {$object-uuid}
        - real stuff, blessed hashes of
            field       => value-or-object
            '.'         => UUID
            '.created'  => timestamp
            '.table'    => table name
- Column/schema info is encoded in the store itself as {$type-uuid-of-Jifty::Model::Type}{*}
    - Introspect/modifiable as any regular model

Limitations

Runtime Typecasting

my $uuid = $typed_record->id; # concat of time and uuid # ...somebody retypes it and stores it... $typed_record->load_by_id($uuid); # oops

Performance

Search

Scalability