On Tue, Feb 12, 2013 at 10:05 PM, Octavian Rasnita <[email protected]>wrote:
> ** > *From:* Bill Moseley <[email protected]> > > If you want to use DBIC in more apps, don't use Catalyst::Model::... but > create a standalone module that can be used from more apps, even in CLI > scripts. > And access that standalone module using Catalyst::Model::Adaptor. > > To be clear, I do have a separate DBIC schema class that can be, and is, used by CLI scripts. I also think it's a good recommendation to use Catalyst::Model::Adaptor instead. Unfortunately, the two apps sharing the schema are years old and followed best practices at the time and used Catalyst::Model::DBIC::Schema. It would be a big project to change at this point. Can anyone explain the reasoning of this code in Catalyst::Model::DBIC::Schema? Why call compose_namespace($class) here? my $class = $self->_original_class_name; ... $self->composed_schema(*$schema_class->compose_namespace($class*)) unless $is_installed; My question is what would break if instead it was just this? $self->composed_schema( *$schema_class *) unless $is_installed; That would allow row object to use their default class. In case that's not clear, in the first code snippet $class is the name of the *Catalyst model* class. For example "MyApp::Model::MyDB". Using that class in compose_namespace means an "Account" row object ends up as "*MyApp::Model::MyDB::Account*" instead of "*Schema::Result::Account*". Again, that is the problem for me because that's the class name that ends up in Memcached when cached and if want to share those cached row object between Catalyst apps it breaks because "OtherApp" doesn't know how to load "MyApp::Model::MyDB::Account" because that class only exists in MyApp. -- Bill Moseley [email protected]
_______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
