- Issue created by @DaveWilliamson
Same here on D 10.1.4 with PHP 8.1. After upgrading from SmartDate 3.7.2 to 4.1.0-rc2 two of my standard SmartDate fields were reported as being in need of such updates. There were no recurring dates involved but a simple "node.field_when" on a testpage and a similar field "commerce_product_variation.field_zeiten" in a set of commerce products. Downgrading to 4.0.3 resolved the issue. - Regards, Andreas
- 🇮🇳India sandipta
You can install devel entity update module and use
drush entup
command to fix the issue. Thanks, but are you sure? I abstained because of the warning on the devel_entity_updates module's page:
"Do not use this to fix the Mismatched entity and/or field definitions error: again, this is not meant to fix production sites."
"If you encounter that error you should identify which module defines the problematic entity type or field definition and open a bug report or support request in its issue queue."
Seems there is a newish module though called entity_update but it may not have the function that is needed here.- 🇨🇦Canada mandclu
The big blocker for me has been getting any sense of what Drupal thinks are the mismatched entity definitions. I know we updated the storage to use bigint, but even on a site where I validated that the DB update ran as expected (I validated that the fields were BIGINT in the DB after) I see the warning.
IMHO it isn't particularly helpful to throw that warning without some feasible way for a maintainer to access the perceived differences. I tried to go into core with debugging tools but I went several levels deep and still didn't get any useful detail
- 🇨🇦Canada mandclu
Having done some more investigation, I believe the issue is that the existing update hook updates the main field table but not the revisions table. Working on a fix.
- 🇨🇦Canada mandclu
To clarify the last comment: by running the database updates, the actual storage in the database table for revisions is updated, but for some reason the stored schema definitions for the revisions table is not. So other than the warning on the status page there should be no functional implications, but still investigating a fix for the warning.
- 🇺🇸United States troybthompson
If it's helpful, I'm also seeing it in Drupal 9.5.11 and Smart Date 4.0.3
- 🇨🇦Canada mandclu
I'm fairly certain that this issue was introduced via the changes in 🐛 Far-future dates cause WSOD, "Numeric value out of range" Fixed . The update added there does update the database tables, but core rejects updating the schema for fields that contain data. The changes currently proposed in 🐛 Timestamp field items are affected by 2038 bug Needs work do introduce a way to get the schema updated, so I will see if I can help that issue along, in addition to investigating a Smart Date-only fix.
- 🇨🇦Canada mandclu
After some investigation into this, the only feasible path forward I've been able too find is by leveraging the optional parameter that would allow for stored schema updates on fields that have data, as proposed in 🐛 Timestamp field items are affected by 2038 bug Needs work . Marking that issue as related, and will see what I can do to help that one along.
- Merge request !70Resolve #3386133 "Node.field_event_recur_date field needs update" → (Open) created by mandclu
- Status changed to Needs review
12 months ago 4:08pm 3 December 2023 - 🇨🇦Canada mandclu
Moving this to Needs Review because in my testing the changes in the merge request successfully resolve the reported error in the Status report, although to do so the site needs to apply the changes from 🐛 Timestamp field items are affected by 2038 bug Needs work , at least the changes to SqlContentEntityStorageSchema.php that introduce handling of the column_changes_handled setting.
Within the comments on 🐛 Timestamp field items are affected by 2038 bug Needs work I did also propose adding the column_changes_handled setting in a separate issue that might be merged more quickly. I did have some challenges getting the changes from that issue's MR merged onto my install of Drupal 10.1.6, so having the smaller set of changes needed here in their own MR would also make getting them applied easier.
- 🇨🇦Canada mandclu
I have also created ✨ Provide a flag to allow updates to stored schema for fields Fixed as a more narrowly scoped way to introduce the change in 🐛 Timestamp field items are affected by 2038 bug Needs work on which the solution in this issue's MR relies. If you have trouble getting the changes in the latter issue to apply cleanly, you should be able to apply the changes in the new issue instead.
can someone put the link here to the fix for this as all I am getting is the git drupal code and unable to do anything with that
- 🇨🇦Canada mandclu
@Willids if you need a patch file you can download one at https://git.drupalcode.org/project/smart_date/-/merge_requests/70.patch
Just remember that before running the new db update provided by this issue's patch, you need to apply the patch from one of the core issues cited above, for example by grabbing a patch at https://git.drupalcode.org/project/drupal/-/merge_requests/5684.patch
- 🇺🇸United States froboy Chicago, IL
I tested this with the "smart_date" module enabled but only using core fields and I received the following warning:
> [notice] Update started: smart_date_post_update_increase_column_storage
> [warning] Undefined array key 0 smart_date.post_update.php:81It looks like the update could use a check for the case where there are no smart_date fields.
- 🇺🇸United States rraney
I believe my problem is related. I had issues with this module after I updated to PHP 8.2. The solution I found was to install the ^4.1 version of the module, which appears to have addressed a PHP deprecation issue.
Since I updated the module, there were two site errors related to the module update. It required a database update. I ran the update. Then I ran drush entup because it said I needed entity updates. I am getting this message in Terminal:
In SqlContentEntityStorageSchema.php line 1750:
The SQL storage cannot change the schema for an existing field (field_smart_date in node entity) with data.
I'm not sure what needs to be done in my case. Do I use a specific patch shown above?
- 🇺🇸United States adrianm6254
Merge request !86 did not work for me. I tried Merge request !70 and found that worked for me in conjunction with `patch at https://git.drupalcode.org/project/drupal/-/merge_requests/5684.patch` as suggested in step #18
- 🇨🇦Canada mandclu
Apologies, Merge request !86 is a work in progress, and not ready for testing yet. I'm trying a different approach that wouldn't require a core patch.
- 🇧🇪Belgium bramvandenbulcke
Will this be fixed in the 4.1.x version eventually? I'm working on a new, to launch project with this error. I could uninstall this version and install the 4.0.x version but that will take some work. If there is a fix in the future for this error, I could leave the error and wait for the fix. Everything is functionally working.
- 🇨🇦Canada mandclu
@bramvandenbulcke The goal is definitely to get this fixed in the 4.1.x branch, in fact getting this issue resolved is the single biggest thing holding the 4.1.x branch back from a stable release.
As mentioned above, installing the linked patch to core and the changes in MR!70 should resolve the warning being displayed. Once the error is gone you should be able to uninstall the core patch as it will no longer be needed for this issue.
That said, there's no way to know when the core issue could be merged much less released, so I opened MR!86 as a potential alternate approach that wouldn't require a core patch, but it still needs some work.
- 🇨🇦Canada mandclu
As an update, ✨ Provide a flag to allow updates to stored schema for fields Fixed has now been merged into core and will be included in Drupal 10.3 and 11. As such, it should be safe to rely on a patch from that issue, and the update in Merge Request !70 to resolve the schema warning. It's also worth noting that once the update has been run and the schema warning dealt with, it should be safe to remove the core patch, if desired.
That said, I still plan to continue the work in Merge Request !86 to see if it's possible to resolve the schema warning without requiring any core changes.
- 🇦🇹Austria maxilein
D10.2.4 Read the thread, but just wanted to add some info. Maybe it is useful.
Just upgraded from Smartdate 4.0 to 4.1 beta 5
$ drush entup
The following updates are pending:node entity type :
The node.field_timex field needs to be updated.Do you wish to run all pending updates? (yes/no) [yes]:
> yIn SqlContentEntityStorageSchema.php line 1750:
The SQL storage cannot change the schema for an existing field (field_timex in node entity) with data.
- Status changed to Needs work
7 months ago 12:05pm 5 April 2024 - 🇸🇰Slovakia coaston
I just applied patch from Merge request 70 (3386133), but still the same issue as reported in #28.
- 🇸🇰Slovakia coaston
Yes.
Update.php showed 1 or 2 pending updates and successfully updated. No issues.
However status report still shows the same and when i try to update field manually -re save the same issue. - Status changed to Needs review
7 months ago 8:40am 13 April 2024 - 🇨🇦Canada mandclu
Merge request !86 is ready for review. Please test that as an alternate fix that does not require any changes to Drupal core.
- Status changed to Fixed
7 months ago 11:05am 20 April 2024 - 🇧🇪Belgium bramvandenbulcke
I updated one site with this issue and after the db updates of 4.1.0-rc7 the errors are no more showing.
- 🇺🇸United States rraney
How do I add this merge request? Can someone point me to instructions? I'm used to using patches.
- 🇺🇸United States rraney
Update: In my case, I needed to do the database updates first, then the entity updates. When I did the correct order of commands, it all works out and I no longer need a patch. I'm not getting errors now after the updates.
Automatically closed - issue fixed for 2 weeks with no activity.