[Dbix-class] Weird behaviour in 0.07999_02

Christopher H. Laco claco at chrislaco.com
Thu Apr 19 17:40:49 GMT 2007


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 wh=
en
> +          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

-------------- 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/84=
fd6a51/signature.pgp


More information about the Dbix-class mailing list