view release on metacpan or  search on metacpan

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

is a datasource subclass wanted to override a parent method
(typically the C<update()> or C<insert()> method), that override
was not always taken into account, depending on whether the method
call was invoked on the proxy object or directly on the datasource object.

The new architecture in version 3.0 dropped the C<ConnectedSource> class :
all method calls go directly to datasource classes. However, a schema reference
still needs to be passed to class method calls : for example in

  $schema->table('T1')->update(-set => ..., -where => ...);

we intend to call the C<update()> I<class method> within the C<T1> Table
subclass. To make this work, C<DBIx::DataModel> twists a little bit
the Perl regular architecture : it creates a temporary C<object> of
class C<T1>, containing only one attribute, namely the reference to the
schema. Methods in class C<T1> recognize such temporary objects and
then behave as class methods instead of instance methods, even if
technically this is an instance method call. By contrast, calls
to C<update()> in 


  my $list = $schema->table('T1')->select(-where => ...);
  foreach my $row (@$list) {
    $row->update({field => $new_value});
  }

are treated as regular instance method calls.



=head2 Separation of steps for the C<update()> method

Previous implementations of the C<update()> method were monolithic, with
all algorithmic steps coded together. Therefore any override of that method
within subclasses had to re-implement every step. This was not very efficient
because the reason to override is usually to modify the update data at a very
specific moment within the algorithm; therefore there is no need to rewrite
the whole process.

The new architecture divides the update into three steps :

=over

=item 1.

parsing the arguments (not a trivial task)

=item 2.

applying handlers and other transformation to the data to be updated

=item 3.

issuing the database request

=back

More precisely, the skeleton for the C<update()> method looks like this :


  sub update  {
    my $self = shift;

    # prepare datastructures for generating the SQL
    my ($to_set, $where) = $self->_parse_update_args(@_);

    # transform the data if necessary
    $self->_apply_handlers_for_update($to_set, $where);

    # database request 
    ...
  }

With this architecture, subclasses can decide to only override the
C<_apply_handers_for_update()> method, instead of overriding the whole
C<update()> method.



=head2 C<Meta::Utils> subroutines instead of methods

Utilies within L<DBIx::DataModel::Meta::Utils> are now subroutines instead
of methods : this makes more sense because that class has no internal state
and therefore is not object-oriented; as a result, calls to these utilities are
less verbose.

=head2 Dependency on L<Scalar::Does> is dropped

L<Scalar::Does> started as a very small and simple module, but then evolved
into a much richer module with more features but also more dependencies.
Since the needs of C<DBIx::DataModel> are very limited, most of the
complexity of L<Scalar::Does> was unused. Therefore the dependency
on L<Scalar::Does> has been dropped, replaced by a very simplistic
implementation of the C<does> method within L<SQL::Abstract::More>.