[Dbix-class] Problem using DBIC in a Catalyst/mod_perl environment with multiple virtual hosts

[Andreas Dembach]

Matt S Trout wrote:
> Andreas Dembach wrote:
>   
>> 1) I could not figure out how to get rid of the initial connect_info set 
>> by the ->config() call that Cat::DBIC::Schema seems to need during 
>> startup, which annoys a little since I do not have any configuration 
>> information during Apache startup.
>>     
>
> Just don't set it, IIRC
>   
That does not work, because otherwise C::DBIC::Schema complains. Brandon
explains why in a post before. I just set it with connect_info that
actually does try to connect to a non-existing DB. What remains is just
one warning in the error log while firing up the apache server, which is
a little annoying, but I can live with that. The real connect_info is
set during the ACCEPT_CONTEXT-call now.
>   
>> 2) I have to cache the schema for each database source, otherwise the 
>> schema/storage/whatever seems to just vanish after returning the newly 
>> cloned schema which results in exceptions like "Can't call method 
>> "source" on an undefined value" or "calling execute on disconnected handle".
>>     
>
> That's not really a problem as such. If you let the object go out of scope it 
> goes out of scope :) if you don't do that you'll end up reconnecting all the 
> time which is pretty gross. The reason you get the exceptions is because a 
> live resultset doesn't keep the $schema in scope, since the alternative would 
> be a circular reference and hence a memory leak.
>
>   
OK, that's good news for us, if caching is no problem from your point of
view. Now that I understand what happens, I could construct our problem
in a little script:

==========#!/usr/bin/perl

  use strict;
  use DB::Main;

  my @all_artists 
  my $schema1                                 'user', 'pass' );

  my $schema2                                 'user', 'pass');

  @all_artists   foreach my $artist ( @all_artists ) {
        print "Queried from test1: " . $artist->name, "\n";
  }

  @all_artists   foreach my $artist ( @all_artists ) {
        print "Queried from test2: " . $artist->name, "\n";
  }

  @all_artists   foreach my $artist ( @all_artists ) {
        print "Queried from test1: " . $artist->name, "\n";
  }

sub get_resultset {
        my $class         return DB::Main->connect('DBI:Pg:database=test2;host=localhost',
                                'user', 'pass')->resultset($class);
}

exit 0;
==========
which results in:

==========Queried from test1: Bar from test1
Queried from test2: Foo from test2
DBIx::Class::Schema::resultset(): Can't find source for artist at
dbix-class-test.pl line 31
==========
In our app we have put such a get_resultset() method in our
schema-class, because we thought it'd be nice to have all DB-related
stuff as central as possible.
Since our  app is pretty large, it was not directly obvious that the
schema gets lost at this point. You might put a warning in the docs
about this behaviour, imho it's a little counter-intuitive.

Big thanks anyway.
Andreas

-- 
-----------------------------------------------------------------
Dembach Goo Informatik GmbH & Co. KG
Andreas Dembach              fon          +49-221-801 483 0
Rathenauplatz 9              fax          +49-221-801 483 20
D-50674 Cologne              emergency    +49-180-50 50 70 919
Germany                      smtp         ad +at+ dg-i +dot+ net
pgp fingerprint 25C2 8C94 015A E92C 3C67  E9B7 2E39 6FFC 277D 6700 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060824/8a1e27c8/attachment-0001.htm