Rohan Almeida’s Blog
Perl Developer. Linux Advocacy. Practicing Guitarist.

4 Responses to “Moose with Rose::DB::Object. Roose? Morose?”

1. john napiorkowski Says:
   May 7th, 2009 at 6:48 pm

   Moose has a lot of ways to be compatible with non Moose based classes. Although several options are ‘baked’ in, there is now a module on CPAN to make it even more clear: “http://search.cpan.org/dist/MooseX-NonMoose/” This module makes is easy to extend non Moose classes into Moose, although you do have other options they might be better such as delegation (see “http://search.cpan.org/~drolsky/Moose-0.77/lib/Moose.pm” and look for the ‘handles’ option on attributes).

   I’d say the main reason why there’s a lot going on between the DBIC (DBIx::Class) group and Moose is that most of the people contributing to DBIC are also heavy Moose contributors. Also, there’s a planned port of DBIC to Moose, which again is going to increase the level of communication between the groups.

2. jdv Says:
   May 7th, 2009 at 7:05 pm

   Good luck. But last time I checked with the rose and moose people this was just not possible.
   Your first hurdle (perhaps the only one) is meta.

3. John Says:
   May 9th, 2009 at 5:44 am

   One issue you may encounter is that both Moose and Rose::DB::Object define and rely on a method named meta(). (For the record, Rose::DB::Object had it first.) This means that you can’t make a Rose::DB::Object-derived class that also inherits from Moose, and you can’t make a Moose class that inherits from a Rose::DB::Object-derived class.

   What people usually do instead is use composition rather than inheritance. That is, make a Moose-derived class that “has a” Rose::DB::Object-derived object within it, rather than one that “is a” (i.e., inherits from) Rose::DB::Object. The reverse will also work: a Rose::DB::Object-derived object that “has a” Moose-derived object.

   Good luck! And don’t forget about the Rose::DB::Object mailing list if you run into any problems: http://groups.google.com/group/rose-db-object

4. Kate Yoak Says:
   April 14th, 2010 at 10:30 am

   I’d like to share what I have recently done to integrate Moose with Rose::DB::Object. It worked out beautifully!

   I went with the advice here: composition/delegation. I also took advantage of autogeneration functionality in Rose::DB::Object::Loader.

   In the end, I have two types of classes associated with the model, the Table classes (RDBO stuff) & the Model classes (Moose stuff).

   package Model;

   use Moose::Role;
   with Model;

   has table => (isa => ‘Table::Object’, builder => ‘_setup_table_obj’, …..);

   sub AUTOHANDLER{
   …
   if ($self->table->can($sub)) { … }
   }

   sub _setup_table_object{
   # change the namespace based on Model’s namespace
   return $table_namespace->new();
   }
   ===
   Model package (the Moose Role) does two important things. First, it defines an AUTOHANDLER, which handles every method my Table object “can”. (There is the fullest delegation: columns, load, save, etc) Second, it sets up all table objects, translating Model::Foo into Table::Foo, and returning the newly intantiated table, saving me all that code.

   Now I can define all the extra non-db-defined stuff in Table::Foo, such as computed methods, additional attributes, etc.

   The beautiful thing that since I am using the Object Loader, the Table namespace doesn’t even have to exist in my code base. (I chose to have it behave that way in development environment, and get “installed” from the database in production. Nothing a Table object contains is ever written by a human. It is a direct translation of the database into perl. On the other hand, Model is all real non-duplicated by database code, and is of course Moose-compliant.

   I really enjoyed putting this system together. And it simplified the release process with respect to database changes, which is always a pain. I shared this here, because I found this page when looking for Rose:DB/Moose combination, so hopefully the next person will get more ideas!

Leave a Reply