[Dbix-class] design issues : about database joins and multiple inheritance

[Dami Laurent (PJ)]

> -----Message d'origine-----
> De : Matt S Trout [mailto:dbix-class at trout.me.uk] 
> Envoyé : jeudi, 25. janvier 2007 11:59
> À : dbix-class at lists.rawmode.org
> Objet : Re: [Dbix-class] plat-form contest starting soon
> 
> 
> Which reminds me, you and I still need to sit down and chat 
> about synergies.
> 
> I reckon I could re-implement the documented interface of 
> DBIx::DataModel atop DBIx::Class in ~3 days and it would 
> actually be quite natural to do so, so I'm more and more 
> suspecting the differences between the projects are largely 
> in terms of how we conceptualise the interface rather than 
> how we actually see the underlying domain.


Okay, now that plat-forms is over, let's start investigating some architectural points. For the discussion I will assume a database schema similar to the one in DBIx::Class::Manual::Example. In DBIx::DataModel, this would be written more or less as 

  # Create a schema class
  DBIx::DataModel->Schema('Music'); 

  # Create table classes
  #               Perl_class  DB_table  Primary_key
  #               ----------  --------  -----------
  Music->Table(qw/Artist      artist    artist_id    /);
  Music->Table(qw/Cd          cd        cd_id        /);
  Music->Table(qw/Track       track     track_id     /);

  # Declare UML associations 
  #                      Class   role_name  multiplicity
  #                      -----   ---------  ------------
  Music->Association([qw/Artist  artist         1        /],
                     [qw/Cd      cds            *        /]);

  Music->Composition([qw/Cd      cd             1        /],
                     [qw/Track   tracks         1..*     /]);


Now if I want information about all recent cds and tracks of some artist, I could write

  my $rows = $someArtist->selectFromRoles(qw/cds tracks/)
	                  ->(-columns => \@some_column_list,
                           -where   => {year => {">" => 2004}},
	                     -orderBy => 'year');

The equivalent SQL is

  SELECT @some_column_list FROM cd INNER JOIN track ON cd.cd_id=track.cd_id
                           WHERE artist_id = $someArtist->{artist_id}
                             AND year > 2004
	                     ORDER BY year

and each row returned by that query will be blessed into a new class 
Music::AutoView::Cd_INNER_Track, created on the fly (if not already there),
and which inherits from both classes Cd and Track. Multiple inheritance 
makes sense here because a row from that result set contains data from both 
tables (Cd and Track).

Now I have two questions :

1) would such an idea (creating classes on the fly and using multiple inheritance) be compatible with the architecture of DBIx::Class ? beneficial ? disastrous ?

2) as far as I understand, DBIx::Class also manipulates the namespace dynamically (loading classes and methods). Did you ever get in trouble when serializing/deserializing such classes through Catalyst sessions, as it just happened to me with DBIx::DataModel ? And if so, how did you solve it ?

Thanks in advance, L. Dami