dev/core#2032 Add potential to vary query log files per process

[eileenmcnaughton]

Overview

Creates option to redirect sql logging output to a new file

Before

All logging of sql queries goes to the same file, subject to log rotation

After

If a truthy value other than the reserved string 'backtrace' is used it will impact the eventual file name of the log.
e.g

env CIVICRM_DEBUG_LOG_QUERY=test_2 drush mycommand

Which would result in the created log file having a name like

CiviCRM.sql_log_test_2.7a880382d2e1d80611365ce1.log

Technical Details

This might be a bit too hacky but I thought I'd put it up for consideration. Basically we have 3 existing
options for CIVICRM_DEBUG_LOG_QUERY

1. FALSE = do nothing (5.30 + or same as TRUE for earlier versions)
2. backtrace = log a full backtrace
3. anything else - log the sql query

This takes a bit of leeway with the 'everything else' and includes the value a part of the
prefix for writing to the query log - allowing something like

Comments

https://lab.civicrm.org/dev/core/-/issues/2032

@totten what is your opinion on this approach? We could add another define & I feel like I could make a case either way

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[totten]

@eileenmcnaughton That seems pretty clever minimalism. For the CLI case, it seems workable - and I can't see any real problems. (If CIVICRM_DEBUG_LOG_QUERY were untrusted input, then there could be problems... but it is trusted input...)

It should be explained more wherever there's documentation for CIVICRM_DEBUG_LOG_QUERY. (Maybe civicrm.settings.php.template?)

The only question I have is how much we care about the web-based case -- e.g. if you're sending requests via web-browser and want to separate the SQL logs. In that case, it might make more sense to name files based on (a) session-id or (b) CRM_Utils_Request::id(). However, both those may be rabbit-holes (b/c SQL starts running early during bootstrap -- possibly before there's a session or request-id).

So I'd put it this way:

• If you expect to also need to separate logs for web requests, then maybe it's worth the harder discussion/design to tackle both in a similar way.
• If you're not expecting to have the web-case, then I think this is fine, and the pithiness is appealing.

[eileenmcnaughton]

@totten I have no current use case for via web but it seems conceivable - we could just add it like

'sql_log' . CIVICRM_DEBUG_LOG_QUERY . $webBasedIdentifier

at some later point if it arises.

[eileenmcnaughton]

@totten I added a docs PR here civicrm/civicrm-dev-docs#853 - the civicrm.settings.php.template doesn't have any existing info about this define but dev-docs does so it seemed a better place

[eileenmcnaughton]

docs pr is merged

[eileenmcnaughton]

@totten OK to merge now?

[totten]

Yup, let's merge based on the previous testing.

[eileenmcnaughton]

Also requires civicrm/civicrm-packages#309