Discussion: Relations #1

tomill opened this Issue Mar 7, 2012 · 3 comments


None yet

2 participants

tomill commented Mar 7, 2012

To begin with, I hope Data::Mapper "Keep it simple" :)

So, how do we implement relation ship system?

This is just my idea, change Data::Mapper::map_data() to

sub map_data {

    # snip ...    

    my $obj = $data_class->new($data);
    $obj->SOMESPECIALMETHOD($self) if $obj->isa('Data::Mapper::Data');

then if the object want to have a child, do this

package My::Mapper::Data::Book;
use base 'Data::Mapper::Data';

    my ($self, $mapper) = @_;
    $self->{author} = $mapper->find(author => { id => $self->param('author_id') });


  • how do u think about this?
  • Is it should support chain action? $mapper->update($book); does $mapper->update($book); AND $mapper->update($book->{author});
  • is it better if $obj->can('SOMESPECIALMETHOD") instead of if $obj->isa('Data::Mapper::Data') for POPO friendly?
kentaro commented Mar 8, 2012

I also want Data::Mapper to be kept simple!!1

First of all, Data::Mapper is a module which implements "Data Mapper Pattern"; that is, basically saying, that Data class has Mapper directly violates the pattern. What the pattern suggests us is independencies between Mapper/Adapter/Data.

Nontheless, I have the same idea of yours. Like your suggestion how to support relationship, I've been actually realizing it in my project like below:


package My::Mapper::Data;
use parent qw(Data::Mapper::Data);

sub mapper {
    my ($self, $mapper) = @_;
    $self->{_mapper} = $mapper if defined $mapper;


package My::Mapper;
use parent qw(Data::Mapper);

sub map_data {
    my $self = shift;
    my $data = $self->SUPER::map_data(@_);

I think it's better for Data::Mapper not to support such an accessor method.

  • It violates the pattern, which leads the module to complexity.
  • We can do that anyway as described above or you suggested ;)
tomill commented Mar 8, 2012

independencies between Mapper/Adapter/Data.

almost agree. I completely agree that Data should not be touchin Mapper. but I think Mapper should know the relationship betwen Adapter and Data.

Your idea, "Create accessor to Mapper in Data using app own subclass" works perfect. but I cannnot be recommended to Data::Mapper users...

My idea is "Give Data one chance to touch Mapper after bless() like Moose's BUILD()". I'm not sure this is good way. Even if use this method, I realized that if $obj->isa('Data::Mapper::Data') is bad idea. I think D::M::Data should be hold as module to use unit-of-work pattern.

I hope to find the good idea to implememt Data-Data relations easy.

kentaro commented Mar 8, 2012

I've been thinking of "Unit of Work" pattern and how to adapt it to Data::Mapper. There has been already an implementation of DM + UoW pattern; DBIx::ObjectMapper. But I prefer a simpler way, so I wrote Data::Mapper.

If DBIx::ObjectMapper/SQLAlchemy/etc work well without session, it's almost good enough. I want the session to be some extensional feature, that is, we could use that modules for simple and handful operation without session at the same time.

Anyway, of course, I'm open to a good implementation. I'm now wondering how I can do it, though...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment