Matt
I stand corrected on DBIx! Yes, indeed I mean DBIx::Class.
The code is in and works, but has a couple of issues. Firstly, it
creates new classes and carries out a DB connect every time there is
a request. Is there a way to make it more efficient by caching the
classes and DB connects once there is a successful authentication?
Secondly, there are loads of 'ACCEPT_CONTEXT redefined' messages, one
per DB table defined to the DBIC model. When initialising, I have to
give the 'dynamic' model an initial configuration to allow Catalyst o
start.
Once the code is working I will pop it on the wiki.
cheers
Nigel
On 17 Aug 2008, at 8:08pm, Matt S Trout wrote:
On Fri, Aug 15, 2008 at 11:05:03AM +0100, Nigel Stuckey wrote:
Another question about multiple databases.
I have an existing application that uses a DBIx DB in the
conventional
way: as a model initialised at run time. All great so far...
DBIx is the CPAN namespace for DBI extensions. There are hundres of
packages in there and you haven't told us which one of them you're
using.
I'm going to assume you mean DBIx::Class but if you want to abbreviate
that please use 'DBIC' - it's really unfair to the authors of other
DBIx:: modules otherwise (compare to people saying Linux 9 when they
actually mean Red Hat Linux 9 or whatever :)
However, I now need to make the application multi-organisation in the
same instance of catalyst: users will select their organisation or
repository when they login or it will be stored as a preference, etc.
Due to the size of the repository, this is implemented as multiple
databases. Thus a single running Catalyst instance will need to open
several DBs sharing the same schema, dynamically after run time. Then
it will have to close unused connections after a while.
What is the best way to do this with DBIx and where is the best place
to store the handles/class references? A key to the active DB can be
stored in the session.
Something like the following (please write this up on the wiki once
you've
got a working version, mine's typed straight into mutt and obviously
isn't -quite- complete :)
package MyApp::Model::DBIC;
use Moose;
extends 'Catalyst::Model::DBIC::Schema';
with 'Catalyst::Component::InstancePerContext';
sub build_per_context_instance {
my ($self, $c) = @_;
my $db_name = $c-session-{db_name};
my $new = $self-new({ %$self });
do something here to make @connect_info from $db_name and config
$new-schema($self-schema-connect(@connect_info));
return $new;
}
1;
--
Matt S Trout Need help with your Catalyst or
DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/
catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment
platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/
servers/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/
catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
