On Tue, Feb 12, 2013 at 10:05 PM, Octavian Rasnita wrote:
> **
> *From:* Bill Moseley
>
> 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
mose...@hank.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/
