Christopher H. Laco wrote:
> Jonas B. Nielsen wrote:
>> Hello,
>>
>> I am currently working on a solution, which is based on Catalyst and
>> Handel. The lastest developments in Handel (0.99_15), requires
>> bleeding-edge DBIx::Class.
>>
>> I have up to now used: DBIx::Class 0.07999_01, but my colleague who set
>> up a new environment installed: DBIx::Class 0.07999_02.
>>
>> This resulted in a weird issue, which was however easily resolved.
>>
>> We have a setup where our namespace is layed out in the following way:
>>
>> FAIadmin/DB.pm
>> FAIadmin/DB/*.pm
>> FAIadmin/RS/*.pm
>>
>> Now when we execute any of our tests related to the DB::* classes, which
>> define a resultset class explicitly like so:
>>
>> package FAIadmin::DB::Customers;
>>
>> __PACKAGE__->resultset_class('FAIadmin::RS::Customers');
>>
>> It breaks with the following error message:
>>
>> Can't locate object method "new" via package "FAIadmin::RS::Customers"
>> (perhaps you forgot to load "FAIadmin::RS::Customers"?) at
>> /Library/Perl/5.8.6/DBIx/Class/ResultSource.pm line 971.
>>
>> The fix is simple:
>>
>> use FAIadmin::RS::Customers;
>>
>> in FAIadmin::DB::Customers
>>
>> What troubles me however is that this just used to work and the change
>> has major impact on stuff we are doing and behaviour in DBIx::Class.
>>
>> Is this a known issue? it has some sideeffect feeling to it, or perhaps
>> it is just me. I am fully aware of the dangers of running on
>> bleeding-edge development code, but sometimes this is that path one must
>> follow :)
>>
>> Another question, which arose with the issue above was, what is the
>> recommended layout of a namespace? as the one I use above or should RS
>> go under DB the following way:
>>
>> FAIadmin/DB.pm
>> FAIadmin/DB/*.pm
>> FAIadmin/DB/RS/*.pm
>>
>> Or is this totally irrelevant, the reason why I ask, was sparked by some
>> of the first feedback I got when inquiring about the above issue on IRC.
>>
>>
>> jonasbn
>
>
> Well, duh... this effected release version as well as the dev
> versions...from ye olde Changes:
>
>
>> -0.07003 2006-XX-XX XX:XX:XX
>> + - Replaced DBIx::Class::AccessorGroup and Class::Data::Accessor with
>> + Class::Accessor::Grouped. Only user noticible change is to
>> + table_class on ResultSourceProxy::Table (i.e. table objects in
>> + schemas) and, resultset_class and result_class in ResultSource.
>> + These accessors no longer automatically require the classes when
>> + set.
>
> _01 was released before _03...
> So, if you were using 0.07003+, you would have this problem.
>
> So, my question is, why doesn't setting result_class automatically load
> that class any more? I thought ensure_class_loaded ot something was
> involved... maybe not...
>
> -=Chrisresult_class AND resultset_class -=Chris
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
