[Dbix-class] Database too big.

Torsten Raudssus getty at cpan.org
Thu Apr 3 13:12:46 GMT 2014


You can just wrap resultset which then dispatches to a second schema
object on this specific resultset-request, if your code really splits
up that 2 so hard, then it might work.

On Thu, Apr 3, 2014 at 2:47 PM, Bill Moseley <moseley at hank.org> wrote:
> I'm looking for some ideas here:
>
> I'm working with a large Postgresql database.  It's getting too large and
> busy. There is an existing DBIC schema for this database that is used by a
> number of applications and tools.
>
> There is a subset of tables in this database that are mostly isolated from
> the other set of tables (i.e. joins are rare).  So, one thought here is to
> pull this subset of tables out into a separate database.
>
> But, then how to minimize the changes needed to all existing code that uses
> DBIC for accessing this database?
>
> One option is to hunt down every use of $schema for the subset of tables and
> replace it with $other_schema.
>
> 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
>
> so the existing application code would not requires so many changes?  (And,
> no, I'm not expecting joins to work across those.)
>
> That is, perhaps have two $storage objects and swap them out based on the
> result source.
>
> I'm sure it's not that simple -- for example thawing serialized DBIC objects
> would need to have the correct storage associated, too.
>
> Any other ideas?
>
>
>
> --
> Bill Moseley
> moseley at hank.org
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk



More information about the DBIx-Class mailing list