[Dbix-class] Working with parts of a database

[Peter Rabbitson]

On Sun, Oct 23, 2011 at 06:45:21PM +0100, Aaron Trevena wrote:
> On 23 October 2011 15:01, Peter Rabbitson <rabbit+dbic at rabbit.us> wrote:
> >> I was wondering what solutions people have come up with for dealing
> >> with database schemas with hundreds of tables..
> >>
> >
> > Dealing in what sense? Please elaborate on the /achieve
> 
> Making it managable in each application or subsystem - it's very rare
> that all the tables and relations are used in every parts of the
> system using a database - if you've got hundreds of classes to load,
> it can eat memory and affect startup times un-nessarily - particularly
> if you're going to be using any automated CRUD/BREAD on top.
> 
> I was just thinking it would be nice to only deal with the
> parts/classes of the schema you actually need in an application or
> subsystem
> 

It is relatively trivial to make individual result classes lazy-loading. In
other words load_namespaces(... { dynamic_load => 1}) or something like that
would still use File::Find to get a list of everything, but will *not* load
each individual file. The reason I say it is simple is because:

1) The entire DBIC source relies on a single call $schema->source to get the
actual result source instance. As such there is a single point which needs
to implement the lazyloading, minimal magic required.

2) Relationships wih fully-specified conditions
(i.e. { foregn.id => self.rem_id } as opposed to 'rem_id'), will *not* load
the foreign result class automatically, which will maintain the lazyness. I
am not aware if Schema::Loader currently has a switch to output such
results, but it will be relatively easy to add.

This has not been implemented purely due to lack of time, not because it is
dificult. Patches welcome! :)

Cheers