[Dbix-class] Enforcing read-only objects

Bill Moseley moseley at hank.org
Wed Aug 11 22:51:16 GMT 2010


On Wed, Aug 11, 2010 at 3:09 PM, Ian Docherty (icydee) <
dbix-class at iandocherty.com>
>
> When you say 'the tests are forgotten' I assume you mean that people
> accessed and modified the DBIC objects directly from within the applicati=
on?
> (For example, by forgetting to call the $foo->set_active method but calli=
ng
> the $foo->active(1) method instead?)
>

No, what I meant is we have been doing what you describe:


> package MyApp::Business::Label;
> use Moose;
>
> has 'dbic_obj' =3D> (is =3D> 'ro', required =3D> 1);
>
> sub set_active {
>    my ($self) =3D @_;
>
>    die "Is Readonly" if $self->dbic_obj->is_readonly;
>
>    $self->dbic_obj->active( 1 );
>    $self->dbic_obj->update;
> }
>

In a very large application with a large number of methods like that.  Then
each one must have that is_readonly test.  It's a lot of repeating.  Of
course, the tests are much more complex.

As developers come and go over time we have had cases where new methods are
added but the validation code is left off or just misunderstood.  That is,
they might forget to add:

 die "Is Readonly" if $self->dbic_obj->is_readonly;



So to avoid repeating and copying code instead:

sub set_active {
   my ($self) =3D @_;

   $self->dbic_obj->active( 1 );
   $self->update;
}

And in a base class:

sub update {
    my $self =3D shift;

    die "Object $self is readonly" if $self->dbic_obj->is_readonly;
    $self->dbic_obj->update;
}

Again, that's pretty close to the dbic layer, so I'm not sure there's much
advantage of that over wrapping DBIC's update() directly.




> This is not all that different from your example, but it would be fairly
> obvious if someone was accessing the ORM directly from your application
> since you would see the use of the 'dbic_obj' accessor.
>

True, that does provide some isolation.

This app provides a REST-like http interface.  All access to the app is via
that interface -- including even cron jobs -- which means the DBIC objects
are completely isolated.  The boundaries between the "app" and "model" are
not always that clear.


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100811/93b=
7c999/attachment-0001.htm


More information about the DBIx-Class mailing list