[Dbix-class] Weird behaviour in 0.07999_02

[Christopher H. Laco]

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 i=
n =

>> +          schemas) and, resultset_class and result_class in ResultSourc=
e. =

>> +          These accessors no longer automatically require the classes w=
hen
>> +          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...
> =

> -=3DChris

result_class AND resultset_class

-=3DChris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070419/4d=
05941f/signature-0001.pgp