Remove unique constraint on block content info field

+++ b/core/modules/block_content/tests/src/Functional/Update/BlockContentRemoveConstraint.php
@@ -0,0 +1,35 @@
+    $this->runUpdates();
+
+    $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
+    $field_storage_definition = $definition_update_manager->getFieldStorageDefinition('info', 'block_content');
+    $constraints = $field_storage_definition->getConstraints();
+    $this->assertCount(1, $constraints);

Should we assert the before state (i.e. that the constraint exists)?

Other than that, this looks good to me

I have fix conflicts and now we target 9.5. Should maybe switch to 10 ?

I also added check that constraint exists as it was proposed in #34

in #27 we started doing a D10 patch. If we are switching back to MRs we should open a separate one for D10. There were additional changes in #27 that should be incorporated, mainly additional testing.

ok, Let's bring your changes to MR and we will target 10 version

LOBsTerr → closed merge request !2050

I am sorry for the spam related to MR. I have decided eventually to close it.
1) I rerolled the patch again 10.1.x
2) Add check that constraint exists
3) Change the number of update hook

Thanks for picking this up!

Per #34

+    $this->runUpdates();
+
+    $definition_update_manager = \Drupal::entityDefinitionUpdateManager();
+    $field_storage_definition = $definition_update_manager->getFieldStorageDefinition('info', 'block_content');
+    $constraints = $field_storage_definition->getConstraints();
+    $this->assertCount(1, $constraints);

Lets add a check before the runUpdates. Count should be 2 before the update.

The last submitted patch, 41: 3272969-41.patch, failed testing. View results →

Hm, I spent too much time on it and I couldn't figure out, why test fails and returns only one contraint :(
I see that we get correct list of constraints in normal Functional tests, but not with Update tests. It is the first time I face something like this. Please direct me here. What I am missing ?

Was also looking at it the other day and think I see why.

We are using drupal-9.4.0.filled.standard.php.gz but the update hook is 10200() wonder if it's not being called?

I'm not super clear if this change goes under update_hook_n or post_update hook. But if we moved to post_update then it should run fine on D9 and D10 I think.

Haven't tested this myself but just thinking.

After deeper investigation the problem is in drupal-9.4.0.filled.standard.php.gz
it contains "block_content.field_storage_definitions" definition without any constraints and even if we try to use post_update, it wont work.

Since we want to be sure that our update hooks works, I will check if "UniqueField" is there. If it is not there I will set it and then it will be removed in update hook. In the case with drupal-9.4.0.filled.standard.php.gz, it would be ok solution.

Also I updated a bit code to check that UniqueField is there

Great find!

diff --git a/core/modules/block_content/block_content.install b/core/modules/block_content/block_content.install
index 772d3e35cdb..b75d59b3360 100644
--- a/core/modules/block_content/block_content.install
+++ b/core/modules/block_content/block_content.install
@@ -37,7 +37,7 @@ function block_content_update_10100(&$sandbox = NULL): TranslatableMarkup {
 }
 
 /**
- * Drop UniqueField constraint.
+ * Remove the unique values constraint from block content info fields.
  */
 function block_content_update_10200() {
   $constraint = 'UniqueField';

This message is shown in the UI at /update.php.

Fixed on commit rather than push back on a simple change.

I checked if there were any database implications here, e.g. indexes to drop etc.

Also checked the status report to make sure there were no entity field definition updates listed, and there were not 🙌

But there are none

MariaDB [local]> show keys from block_content_field_data where column_name ='info';
Empty set (0.001 sec)

MariaDB [local]> describe block_content_field_data;
+-------------------------------+------------------+------+-----+---------+-------+
| Field                         | Type             | Null | Key | Default | Extra |
+-------------------------------+------------------+------+-----+---------+-------+
| id                            | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id                   | int(10) unsigned | NO   | MUL | NULL    |       |
| type                          | varchar(32)      | NO   | MUL | NULL    |       |
| langcode                      | varchar(12)      | NO   | PRI | NULL    |       |
| status                        | tinyint(4)       | NO   | MUL | NULL    |       |
| info                          | varchar(255)     | YES  |     | NULL    |       |
| changed                       | int(11)          | YES  |     | NULL    |       |
| reusable                      | tinyint(4)       | YES  |     | NULL    |       |
| default_langcode              | tinyint(4)       | NO   |     | NULL    |       |
| revision_translation_affected | tinyint(4)       | YES  |     | NULL    |       |
| content_translation_source    | varchar(12)      | YES  |     | NULL    |       |
| content_translation_outdated  | tinyint(4)       | YES  |     | NULL    |       |
| content_translation_uid       | int(10) unsigned | YES  | MUL | NULL    |       |
| content_translation_created   | int(11)          | YES  |     | NULL    |       |
+-------------------------------+------------------+------+-----+---------+-------+
14 rows in set (0.002 sec)

MariaDB [local]> 

Published change record

Automatically closed - issue fixed for 2 weeks with no activity.

The name of the function of the hook_update_N should have been:
block_content_update_10101
instead of
block_content_update_10200
because the core version is 10.1