Dave Howorth wrote:
>> So that's why Class::DBI::mysql ends up behind Class::DBI in the
>> inheritance and in consequence the wrong version of column_type
>> gets called.
>
> It's late and I'm going to bed now :)
>
> It needs a clearer mind to think about a proper patch.
Last night, I missed stating what I see as the requirements for a solution:
(A) The M-M-CDBI model base class should not inherit from C-DBI.
It should first call C-DBI-Loader, which decides the appropriate flavour
of C-DBI to inherit from (C-DBI-mysql, C-DBI-SQLite etc) and creates all
the classes for the tables with that base class.
(B) But the other useful thing that the M-M-CDBI base class does is to
_use_ all the additional C-DBI-* modules (AsForm, FromCGI etc). To do
that, for some of them at least, it needs to inherit from C-DBI or a
subclass (so the C-DBI-* modules can call set_sql in their startup).
So that's the dilemma. M-M-CDBI shouldn't inherit from C-DBI (A), and it
should (B).
Now it's morning, I see an obvious evil patch that's a variation of my
experiment last night. Simply start with the original M-M-CDBI that
*does* inherit from C-DBI so that all the C-DBI-* modules can be used.
Then at the end of setup_database(), once the loader-determined C-DBI
subclass is known, _remove_ C-DBI from M-M-CDBI's @ISA and substitute
the C-DBI subclass.
However, that's a fairly nasty bit of hackery, and the problem I've
stated here (the contradiction of A and B) is not specific to Maypole.
It only depends on C-DBI. It's a pattern that probably occurs commonly
in other CDBI apps. Is there a well-known idiom to solve it?
Cheers, Dave
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT