=head1 name
Jifty SVK Model docs
=head1 SUMMARY
=head1 IMPLEMENTATION
=head2 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
=head2 Implementation plan
=head3 Functionality
=over
=item create objects
=item read objects
=item find objects
=item update objects
=item delete objects
=back
=head3 API
- First step is a memory-only, svn-compatible layout backend store
- Composed of alternate implementation of APIs of:
- Jifty::Record
- Jifty::Collection
=head4 Jifty::Record
Methods:
=over
=item create
=item set
=item value (get)
=item delete
=item
=back
=head4 Jifty::Collection
=over
=item next
=item items_array_ref
=item unlimit
=item 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() } )
=back
=head2 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.
=head3 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
=head2 Limitations
=head3 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
=head3 Performance
=head3 Search
=head3 Scalability