Repository navigation
Fixes
-
A cache backend going down no longer takes the application with it. When the engine behind
_cake_model_is unreachable it logs its own connection failure, which built this log engine, which instantiated the logs table, which asked for the schema cache again. That cycle allocated on every pass and only ended when the process hit its memory limit. Two changes break it: lazy creation of thedatabase_logstable is now restricted todebugmode, andensureTables()refuses to reenter while a schema lookup is already in flight. (#73, #74) -
The log engine no longer throws. A write that cannot reach the database used to propagate out of
Log::write()into whoever calledLog::error()- code that is usually already reporting a problem and has no way to handle a logging failure on top of it. The entry now goes to PHP'serror_log()prefixed with[DatabaseLog fallback], so it is recorded rather than lost. The table is also resolved on the first write instead of in the constructor, so building the engine cannot fail either. (#74)
Upgrading
Lazy auto-creation of the database_logs table now happens in debug mode only. It previously ran in every environment unless DatabaseLog.disableAutoTable was set to true.
If you relied on the table being created for you in production, either run the migration once:
bin/cake migrations migrate -p DatabaseLog
or restore the old behavior explicitly:
'DatabaseLog' => [
'disableAutoTable' => false,
],The config key now overrides the default in both directions: true never auto-creates, false always does, and null (the default) means debug mode only.
Because the log engine no longer throws, a failed log write that previously surfaced as an exception now appears in the process error log instead.
See Upgrading for details.
Full Changelog: 4.6.1...4.7.0