[Dbix-class] object as a value of result_class (resultset_class)

Eden Cardim edencardim at gmail.com
Sat Sep 24 16:39:11 GMT 2011


>>>>> "neil" == neil lunn <neil at mylunn.id.au> writes:

    neil> There are varying approaches to this, from related tables for different
    neil> object properties to object serialization/deserialization in something like
    neil> a clob.

This is what KioukuDB does. :)

    neil> Especially with the related tables approach and getting fancy
    neil> with prefetch, I tend to prefer the abstraction approach.

>>>>> "Roman" == Roman Daniel <roman.daniel at davosro.cz> writes:

    Roman> Yes, it is exactly from the mould of Person -> Student,  Person -> Worker, ...

    Roman> In past I got quite frustrated with how little information I
    Roman> found about coping with polymorphism in DBIC environment. It
    Roman> seemed that this is the problem that almost everyone has to
    Roman> come across :-( I appreciate any link to this topic.

You haven't found any information on how to do it because the way you're
proposing to do it is wrong. Neil's suggestions are the best
approaches.

    Roman> package MySchema::Dispatcher::Person;

    Roman> sub inflate_result {
    Roman>      my ($this, $result_source, $me, $prefetch) = @_;

    Roman>      my $subclass = $me->{something} eq 'anything' ?
    Roman> 'MySchema::Result::Person::Worker':
    Roman> 'MySchema::Result::Person::Student';
    Roman>      return $subclass->inflate_result($result_source, $me, $prefetch);
    Roman> }

That approach will be a nightmare to maintain. For starters, you will
have to run everything inside transactions to guarantee that the value
of $me->{something} doesn't change in the database, throughout the life
of the inflated object. If the inflated object writes any changes to
that column, you will have to rebless the object. This will require you
to cross-check the inflator to make sure you're not writing onto a
column that warrants a rebless. You can automate that, of course, but
it'll become quite hard to maintain code where objects keep changing
classes magically behind the scenes. You can of course, abstract the
objects and not make any assumptions about the specific classes of the
objects you're working with, but then what's the benefit of reblessing?

You're better off by creating three tables, a person table, and
worker/student tables containing the specific data and a 1-1
relationship to the person table. This approach has a lot less caveats
than the one you're proposing.

-- 
  Eden Cardim
  Code Monkey                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://blog.edencardim.com/            http://www.shadowcat.co.uk/servers/
http://twitter.com/#!/edenc



More information about the DBIx-Class mailing list