Re: [GMOD-devel] [Gmod-architecture] DBIx::Class

[Robert B. <rm...@co...>]

OK, this is the third time I'm sending this, because it still has not 
shown up on the gmod-architecture list.  Maybe chris and kim and 
siddhartha have already gotten it, I don't know.  R

========

Chris Mungall wrote:
> the way to do this. What's the best practice in the dbic community? 
> Chado can't be that unusual in it's FK naming conventions?
I think most people just shrug and remember that the _id() things are
actually relation accessors when they're using the layer.  Doesn't mean
me can't remove them if we want though.

> I have a sense that a lot of the time the raw dbic classes may be too 
> low-level for doing certain operations, so we may end up subclassing 
> these classes to add extra smarts.
Yes, probably.  The most common patterns for this are adding code to the
generated classes themselves, subclassing them, and defining custom
resultsets (from custom sql queries and such).  However, anything that's
not directly related to low-level schema use belongs somewhere other
than in this distribution.

> Some further downstream objectives
> 
> * interoperation with other perl libraries, such as bioperl (possibly 
> targeting Bio::Moose) for the sequence module and the new moose based 
> go-perl (http://wiki.geneontology.org/index.php/GO_Moose). I'm not yet 
> sure whether the best way to do this is via a loosely coupled bridge 
> layer, or something cleverer using the tighter moose integration with 
> the forthcoming version of dbic
The next generation of bioperl (currently called Bio::Moose) is probably
going to move away from the monolithic distribution model.  Much easier
to maintain and release that way.  Then, seems to me that dbic-chado
integration with bioperl would be in a bioperl dist that depends on
dbic_chado and the relevant bioperl dists, and provides e.g. a
Chado::Feature module.

> First of all, I wouldn't be all that surprised if there wasn't another 
> dbic layer out there, perhaps with its own unique properties. We should 
> get all players involved in a discussion first. I have a sense gmod-arch 
> is not widely read? maybe we should announce plans on gmod-devel or 
> gmod-schema?

Yes, good idea.  I'll write something there.

Rob