Currently, when applying filters to a model this will run model::_init(), doing lots of stuff including getting connections and running actions on the backend (eg describe in the case of mysql database).
The issue: applying filters to models in the bootstrap and having connections set up like Connections::add('default', array('development' => array())); results in 'No adapter set for configuration in class lithium\data\Connections'. This will only work when the dispatcher filter has run and set the environment.
Applying filters on models in bootstrap only works when connections do not have an environment key.
Having no environment key in your Connections and applying filters to models in the bootstrap will also require a functional backend when running units tests (that do not require the backend) for your application.
Connections::add('default', array('development' => array()));
The solution (workaround?) now is to have that part of the bootstrap executed in the dispatcher filter (creating thus a bootstrapped bootstrap), or somewhere else in the dispatcher execution chain.
I would rather see that model filters can always be configured in the normal bootstrap process and the connection to the backend is only made in the dispatcher execution chain and not during the bootstrap.
Some parts of the _init should be run directly. Can those parts of _init needing a fully configured environments
(and perhaps the more expensive ones) be delayed till they are really needed? Eg, in the data branch the relationships are already made lazy.
Bonus: when applying filters for multiple models in the bootstrap this will currently cause all those models to be fully configured and connected while only some need to be for that request. Having a more lazy init will make the bootstrap less demanding.
Added a section in the docs: UnionOfRAD/manual@95620bd.
Nice hidden treasure, at least until recently.