view release on metacpan or  search on metacpan

lib/DBIx/DataModel/Doc/Design.pod  view on Meta::CPAN

=head2 Why this C<localize_state> method ?

When C<DBIx::DataModel> is in
L<single-schema mode|DBIx::DataModel::Doc::Glossary/"single-schema mode">,
the schema is a global resource within the application, very much
like other Perl global resources (for example
C<STDIN>, C<%ENV>, or special variables C<$/>, C<$,>, etc.).

When used with care, interaction of several components through a
global resource can be quite handy : for example C<STDIN> does not
need to be explicitly passed to every component, it is always
available; furthermore, C<STDIN> can be redirected at one specific
place and then all collaborating components will immediately change
behaviour accordingly. However, this must be done with care, because
there is also a risk of undesired "action at distance" --- maybe the
other components wanted to continue reading from the real C<STDIN>,
not the redirected one !

To avoid undesired interactions through the global state, Perl offers
the C<local> construct, also known as I<dynamic scoping> (see
L<perlsub>). Using that construct, a component can temporarily
redirect C<STDIN> for the duration of one specific computation, and
then automatically restore it to its previous state.

The
L<localize_state|DBIx::DataModel::Doc::Reference/localize_state>
method of C<DBIx::DataModel> uses a similar approach : it
supports a temporary change to the global schema state (for example
for changing the database handle), and then restores
the schema to its previous state.
That method is also called implicitly by 
L<do_transaction|DBIx::DataModel::Doc::Reference/do_transaction>.


=head2 Serialization

C<DBIx::DataModel> includes support for the standard
L<Storable|Storable> serialization / deserialization
methods C<freeze> and C<thaw> : so records and record trees
can be written into files or sent to other processes.
Dynamic subclasses for database joins are re-created on the fly
during deserialization through C<thaw>. However, there is no support
for serializing database connections (this would be hazardous, and also
insecure because serialization data would contain database passwords).
Therefore the process which performs deserialization is responsible
for opening the database connection by its own means, before
calling the C<thaw> method. 

=head1 TO DO


Here is a list of points to improve in future versions C<DBIx::DataModel> :

  - 'has_invalid_columns' : should be called automatically before insert/update ?
  - 'validate' record handler (at record level, not only column handlers)
  - walk through WHERE queries and apply 'to_DB' handler (not obvious!)
  - add PKEYS keyword in -columns, to be automatically replaced by
    names of primary key columns of the touched tables
  - pre/post callbacks: support arrays of handlers, refine(..) should add
    to the array
  - refine(-order_by => ..) should add to the ordering
  - update with subtrees (insert/update on dependent records. Quid: delete?)
  - auto-unjoin (API for partioning columns into subobjects).
  - support DISTINCT ON ...
  - support find_or_create, update_or_create
  - copy idea from DBIC:Storage:DBI:MultiColumnIn
  - Storable
     - hooks for YAML ?
     - think about STORABLE_attach
     - think about freeze/thaw in multi-schema mode
  - readonly tables
  - savepoints
  - explain how to design families of tables with an intermediate superclass
  - tune croak() in Statement.pm so that SQL errors are reported 
    from caller's line
  - $obj->join(path1 ...)->select(...) should automatically add
    -result_as => 'firstrow' when all multiplicities are 1. See TODO
    in ConnnectedSources::join
  - check auto_insert / auto_update columns to prevent intersections