Problem/Motivation
date_update_7007 loops over all datestamp fields and unconditionally calls db_change_field on some tables. On sites using the core provided Field SQL Storage backend, this is fine and will work fine. If you have configured a different field storage backend and are using it for datestamp fields, then the update hook will fail.
Steps to reproduce
Use a different field storage backend that doesn't create the same tables as the core field_sql_storage backend, have a datestamp field, and run the update hook.
Proposed resolution
You can't cater for all the field storage backends out there, which is why the API for doing these field schema changes never made it into D7 core properly. So instead, we should cater for the 99.9% of people using field_sql_storage, but not break for the other 0.1%.
Add a db_table_exists call around the existing code.
Remaining tasks
Code the patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | date-3163293-date_update_7007-6.patch | 1.04 KB | steven jones |
| #4 | date-3163293-date_update_7007-4.patch | 794 bytes | steven jones |
Comments
Comment #2
joseph.olstadComment #3
joseph.olstadah, no patch to review
Comment #4
steven jones commentedComment #5
steven jones commentedOh, and actually as pointed out in #2016787-15: Far dates causes PDOException 22003 this will fail when there are other columns too.
Comment #6
steven jones commentedSo this updated patch targets just the value and value2 columns, which are the only ones that need changing anyway.
Comment #7
joseph.olstadThe added checks are an improvement, well done.
Comment #9
damienmckennaCommitted. Thank you Steven!
Comment #10
joseph.olstadw00t! thanks DamienMcKenna!