[Dbix-class] Database too big.

[Bill Moseley]

On Thu, Apr 3, 2014 at 7:07 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:

> On Thu, Apr 03, 2014 at 05:47:18AM -0700, Bill Moseley wrote:
> >
> > One option is to hunt down every use of $schema for the subset of tables
> > and replace it with $other_schema.
>
> This is what I would recommend. Can you give ideas of the scale of
> changes required?
>

Hard to quantify.  It's a few big apps and command-line utilities.   It's
just normal work to hunt down every possible usage.   Making lots of
changes has its risks, too.

But, not everything is as simple as literal $schema->resultset( ... ) lines
everywhere, of course. There's code that says "Oh, this things works with
"Foo", or this is "Foo" controller so I'll use $schema->resltset( 'Foo' )".
That is, much of the high-level code assumes a single $schema.

DBIC is the common later, which would make it handy to solve there.

> But, is there anything I might do that is a bit more "clever"?:
> >
> > $schema->resultset( 'Foo' )  # uses one database
> > $schema->resultset( 'Bar' )  # uses a different connection
>
> A schema object is by definition a "proxy that ties mutliple sources and
> a *single* storage object together". As such cleverness in this area is
> likely to bite you. I can not think of specifics at this moment, but the
> gut feeling is "don't do it".
>

Well, gut felling is a valid response.

Perhaps a different animal, but the replication code manages multiple
database connections which made me think about doing something similar at
the $storage layer.

Thanks,


-- 
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20140403/87270f9e/attachment-0001.htm>