On Thu, Apr 3, 2014 at 7:07 AM, Peter Rabbitson <rabbit+d...@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 mose...@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
