Re^3: Search for ORM with Multi-Table-Object Support

[Your Mother]

It might just be personal bias but that feels messy compared to the affordance it gives. You could potentially do the same thing with Moose using handles on the foreign objects attributes. That seems like a mistaken can of worms and a performance ding though… As you mentioned, you could write your own shortcut routines and you could make it semi-lazy with has_column_loaded.

There are two natural ways you can do some of what you want in DBIC. The first is keeping the DB in line with the code: a VIEW. This is mysql syntax–

CREATE VIEW uview AS
  SELECT
       u.id
       ,u.username
       ,c.name
       ,c.address
       ,p.text
       ,p.image
  FROM user u
       ,contact c
       ,profile p
  WHERE c.user = u.id
        AND
        p.user = u.id
        ;

And then you create a regular DBIC result class for it. I tried a loader with dbicdump and it seems to work just fine.

Alternatively you could do a DBIC in-code view class. With __PACKAGE__->result_source_instance->is_virtual(1) and the same SQL as the result_source_instance->view_definition. Both of these suffer from returning readonly objects and the real VIEW additionally will likely create real, and ultimately useless/confusing, tables upon deployment while the in-code view will not. (Update: it occurs to me that could put the is_virtual on the real VIEW too to keep it from creating a new table on $schema->deploy… but I didn't test and it's not put in by the loader/dumper defaults.)

But for convenience and a sort of permanent join/prefetch this would do what you want (as long as you only want to read).