I use d7 to d8 migrated site as base.

When I goes to admin/config page i got

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1364 Field 'uri' doesn't have a default value: INSERT INTO {locale_file} (filename, uri, project, langcode, version, timestamp, last_checked) VALUES (default, default, :db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => drupal [:db_insert_placeholder_1] => ru [:db_insert_placeholder_2] => 8.0-dev [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 0 ) в функции drupal_write_record() (строка 475 в файле /home/dev/domains/d8.dev.bighameleon.com/core/includes/schema.inc).

My debuging shows me that if I turn off Interface Translation module error gone.

Patch attached to this issue fix trouble for me but I'm not sure if it fix it in right way

#5 drupal8.language-system.2048379-5.patch727 bytesXen
PASSED: [[SimpleTest]]: [MySQL] 59,060 pass(es). View
#4 2048379-uri-4.patch646 bytesandypost
PASSED: [[SimpleTest]]: [MySQL] 57,488 pass(es). View
uri_field_no_def_value.patch643 bytesniko-
PASSED: [[SimpleTest]]: [MySQL] 57,463 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


andypost’s picture

Title: multilengual first time admin/config exception Field 'uri' doesn't have a default value into {locale_file} » multilingual first time admin/config exception Field 'uri' doesn't have a default value into {locale_file}
Issue tags: -i18n +D8MI

fix tags

andypost’s picture

andypost’s picture

646 bytes
PASSED: [[SimpleTest]]: [MySQL] 57,488 pass(es). View

I think uri should be always initialized

Xen’s picture

727 bytes
PASSED: [[SimpleTest]]: [MySQL] 59,060 pass(es). View

The issue is not the missing initialization, the underlying problem is that locale_update_8015() does not create the same table as locale_schema() does (it's missing default, description and the type is wrong).

Attached patch brings the update hook in line.

However, whether that's enough is the question. Depending on how the upgrade path between alpha releases is defined, we should instead create a new update hook that fixes up after locale_update_8015(), just as locale_update_8015() fixes up after locale_update_8010() (which also creates the table, but in an earlier version). In that case, we should remove the code from locale_update_8015() and locale_update_8010(), and let the new update hook drop the table, if it exists, and create it properly.

If someone could confirm that the attached patch here isn't enough, and we need the big version, I'll create a new patch.

andypost’s picture

andypost’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Since we have no upgrade tests, and patch makes sense

webchick’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

Since we are no longer doing a 7 => 8 upgrade path, in favour of Migrate module, I believe unfortunately I need to do this. :(

andypost’s picture

Status: Closed (won't fix) » Reviewed & tested by the community

@webchick this is a bug in current codebase that should be fixed, this will make no sense only when we get rid of this update function

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, fair enough.

Committed and pushed to 8.x. Thanks!

Status: Fixed » Closed (fixed)

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