Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.As reported by Dave Kopecek in #3114128: Adding rrule_index to smart date field schema:
I'm getting this error when I update to the 03/04/2020 version:
drush -y updb
------------ ----------- --------------- ---------------------------------------------
Module Update ID Type Description
------------ ----------- --------------- ---------------------------------------------
smart_date 8202 hook_update_n Add rule index column for recurring dates.
------------ ----------- --------------- ---------------------------------------------
// Do you wish to run the specified pending updates?: yes.
> [notice] Update started: smart_date_update_8202
> [error] SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'field_date_and_time_rrule_index': ALTER TABLE {node__field_date_and_time} ADD `field_date_and_time_rrule_index` INT unsigned NULL DEFAULT NULL, ADD INDEX `field_date_and_time_rrule_index` (`field_date_and_time_rrule_index`); Array
> (
> )
>
> [error] Update failed: smart_date_update_8202
[error] Update aborted by: smart_date_update_8202
[error] Finished performing updates.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | duplicate_index_patch_smart_date_8202.patch | 445 bytes | stefan.korn |
| #8 | smart_date-update_error-3118376-8.patch | 1.01 KB | mandclu |
Comments
Comment #2
mandclu commentedCan you test this patch to see if it solves your issue?
Comment #3
jurgenhaasRan into the same issue. In my case it happened because the module smart_date_recur was NOT enabled and then the entity type is missing. So, I'm wondering if this update should partly or fully move into that submodule instead?
Comment #4
mandclu commentedI originally tried to keep all the code for the extra column (originally just rrule, but now joined by rrule_index) within smart_date_recur, but based on my testing it seemed as though a submodule could remove a column (and add it back, if needed) but not add column that wasn't part of the original schema.
@jurgenhaas it sounds like your error could be different. Can you provide the text of the error you encountered?
Comment #5
jurgenhaasUnfortunately, I don't have a record of the error message. It said something like
Entity type smart_date_rule does not exist.Comment #6
mandclu commentedI really can't see where the smart_date_rule entity is referenced outside of the submodule. Did you have it installed previously?Edit: I think I see the problem. I'll try to post an updated patch shortly.What versions are you updating between?
One other thing to try would be running Devel Entity Updates.
Comment #7
jurgenhaasI installed version 2.0 early last week and only enabled the main module. On Friday I then updated to version 2.1 and ran
drush updatedbwhich responded with the error. As it is a live project where we had to deploy to a staging server for the customer to review progress, I enabled the submodule as a quick resolution and hence can't reproduce the problem on that project anymore.No, the submodule was not installed previously.
Comment #8
mandclu commentedOK please try this updated patch.
Comment #9
jurgenhaasWell, as mentioned in my previous comment I can't reproduce the problem anymore as we had to move on last Friday and resolved it by enabling the submodule.
Comment #10
inst commentedHi,
I also get an error after updateoing from smart_date 8.x-2.0 to smart_date 8.x-2.1.
After trying to make an update database run I get:
Modul smart_dateAktualisierung #8202Fehlgeschlagen: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "smart_date_rule" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (Zeile 150 in /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
BUT after activating the Smart Date Recurring - the error is gone after a next try of update database run.
Comment #11
jurgenhaasThat's the one I got too. And it comes from
$rules = \Drupal::entityTypeManager()->getStorage('smart_date_rule')->loadMultiple();insmart_date_update_8202(). I think that part should be moved into the install file of the sub-module.Comment #12
mandclu commentedThe patch in #8 adds a check if the submodule is installed before before trying to run that, which should solve the problem.
@inst did you try the patch?
Comment #13
jurgenhaasThat should do, right. But still, the update process is mis-located. It is within scope of the sub-module and not the main module, isn't it?
Comment #14
inst commentedOk, I did an other test (without using the patch).
After deinstalling the submodule again - still the error does not come back.
Comment #16
mandclu commentedIt sounds like the workaround of installing the submodule to run the update does the trick permanently, which is great to know. Also committing the patch to avoid the error altogether for anyone else updating. Thanks for all the feedback everyone.
Comment #17
stefan.kornI suppose the error that @Dave Kopecek was experiencing is different from the one that @jurgenhaas was experiencing and I think the patch might not solve the error of @Dave Kopecek. It seems that the index name that was generated for the rrule field conflicts with the index name that is designated for the rrule_index field.
This might be due to a change in the _smart_date_field_columns_add() function between 8201 and 8202 update hooks (I was involved here). Though I could not reproduce the error by myself, I suppose this is happening when coming from an old alpha version of 2.x or even from 1.x.
The following patch might solve this issue. But this patch should only be used if experiencing this issue. And it even seems advisable to remove the patch after the update has been applied.
Comment #18
cajewell commentedWhen updating from Smart Date 2.0 to 2.2, I had the same database error. @stefan.korn, the patch you added in #17 worked for me. So far, I've only applied the patch to development sites, but I'd really like to add it to a production site in the near future. Could you please clarify your last paragraph? Why does it seem advisable to remove the patch after the update has been applied? Thanks in advance.
Comment #19
stefan.korn@cajewell: The patch is going back to a previous version of the function that adds an index for a new column in the db. This is needed to fix the error, but after the fix the current version of the function can be used again. Though at this moment it is not clear whether the function will be called again anytime soon, since the function is only needed when adding a new column to the database and this is usually happening not very often. And I do not suppose that this problem will happen again even if a new column will be added, since it was a rather special duplicate naming scenario. So it seems the best solution to me, to remove the patch after fixing the error. That way you are not forced to carry a patch with your module, as this is always a little annoying.
So my recommendation would be to use the patch and do the database update and after that remove the patch again.
But first make sure you have the exact error that @Dave Kopecek is describing in the issue summary (This goes out to anyone else maybe reading this).