The startup manages to display the entire debug and diagnostics of Catalyst, which looks particularly odd in the middle of the tool’s run.

I think I can even agree that it is probably not a good general solution.

I can live with this, because this tool is something only a developer will see.

I can also live with it because trying to figure out how to extract the model names and connection information from Config::JFDI – which I have already used in this program! – and being able to find the real DBIC class and get it created without the model’s help was driving me crazy.

The Catalyst app in question uses several models, from several sources, and Catalyst has already got the code internally to read the config, find the models, load them, figure out where they really are, and be able to create usable handles from then.

Why should I work to duplicate all that code, in a likely fragile and hard to maintain way (actually, I gleefully threw out some horrid and sort of working code) when Catalyst already knows how to do all this for me?

(Yes, this is me saying, “I already had a bulldozer, and didn’t want to drive across town and get a shovel.”)

Your point makes me wonder if another module to use the data from $config to load all the right DBIC classes might be worthwhile. It would certainly be more appropriate for general use.