Improve errors on failed db updates
- Dominant language
- PHP
- Stars
- 45
- Forks
- 36
- Avg merge
- 17h 54m
- Merged PRs (30d)
- 3
Description
Doing:
> $ cv upgrade:db --dry-run
> Found CiviCRM database version 5.17.4.
> Found CiviCRM code version 5.23.4.
> ...
found no problems. Running the upgrade for real failed (not sure if dry-run could catch that) and dumped a webpage with this text:
```
Sorry, due to an error, we are unable to fulfill your request at the
moment. You may want to contact your administrator or service provider with more details about
what action you were performing when this occurred.
```
*DB Error: no such field* is almost useless, but -vv at least provides a clue where to start looking, in this case:
`CRM_Upgrade_Incremental_php_FiveEighteen::runSql(5.18.alpha1)`
Is there no way to make the default reported error be more verbose, in this case printing the field name and/or dumping the query (debug_info member) and/or filename?
*(not important, but the actual problem seems to have been in the later steps, since .20 introduced frontend_title to civicrm_contribution_page, which was missing the localized columns)*
Contributor guide
No contributing guide indexed for this repository
Research direction
Start at the cv upgrade:db error path and the CRM_Upgrade_Incremental_php_FiveEighteen::runSql(5.18.alpha1) entry point mentioned in the report. Inspect how the default database error is assembled, including the debug_info member, and determine how to expose actionable context such as the field, query, or filename. Done means failed updates provide more useful default diagnostics than “DB Error: no such field”.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- cli, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100