=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