On 20/09/2011 7:59 PM, Roman Daniel wrote:
In my app I store instances of several classes (subclasses) in one table.
I try to implement a dispatcher which decides what class to inflate to
according to row data loaded from db.
It seems handy for this dispatcher to be an object instead of class.
In DBIC the setter for result_class is implemented via set_component_class,
which expects its argument to be a class - Class::Inspector->loaded is
called on it.
I note that this is not really where you are going with this from your
following passage, and that perhaps it's something you might find a more
timely/lively discussion on irc about. I'm not do sure I'm all to hot
about result_class being an object/instance rather than a class though.
However it seems to me that what you are generally describing is
something in the mould of a Person -> Student, Person -> Worker,
polymorphic set of relations in your data structure defined by the
underlying elements.
So for my money, and I know this might sound like a lot of duplicative
work, I'd being looking at implementing your dispatcher as a ResultSet
processor inflating the result rows into the respective classed objects.
Meaning think of this as an abstraction layer on top of the DBIC classes
representing the "table" schema and more as the polymorphic object
collection, aware of the underlying resultset objects.
There are varying approaches to this, from related tables for different
object properties to object serialization/deserialization in something
like a clob. Especially with the related tables approach and getting
fancy with prefetch, I tend to prefer the abstraction approach.
I can overwrite set_component_class to fallback to set_inherited when
its argument is a blessed object, but I am not sure whether the whole
idea is not weird. If not do you plan to allow result_class to be an
object? (it can be set to object even now but a warning is issued by
Class::Inspector)
I appreciate any comment
Roman Daniel
After I sent the message I noticed that result_class being a class is
also expected in compose_namespace (used in
Catalyst::Model::DBIC::Schema), where subclasses of result_classes
are created.
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
