From 666a7bba29eae89abe0fd7e3c92457d705fa3785 Mon Sep 17 00:00:00 2001 From: Alex Taranovsky Date: Wed, 16 Oct 2019 16:34:52 +0300 Subject: [PATCH 1/3] magento/devdocs#: schema.db does not support ON UPDATE action for constraints https://devdocs.magento.com/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.html --- .../declarative-schema/db-schema.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md index 0f281b1d707..373e223a6f6 100644 --- a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md +++ b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md @@ -5,9 +5,9 @@ title: Configure declarative schema Before Magento 2.3, extension developers were required to write code (PHP scripts) to change the database schema. The following types of scripts existed before Magento 2.3: -* InstallData and InstallSchema scripts, which are executed the first time a module is installed. -* UpgradeData and UpgradeSchema incremental scripts, which supplement an existing module schema. -* Recurring scripts, which are executed each time you install or upgrade Magento. +* InstallData and InstallSchema scripts, which are executed the first time a module is installed. +* UpgradeData and UpgradeSchema incremental scripts, which supplement an existing module schema. +* Recurring scripts, which are executed each time you install or upgrade Magento. Each script iteratively adds changes. During the installation process, upgrade scripts apply only those changes that have not been applied yet. For example, if you have a module with version 2.1.8 installed and the latest version is 2.1.11, then the upgrade script changes for 2.1.9, 2.1.10, and 2.1.11 will be applied, in order, when you upgrade to 2.1.11. Each upgrade script is responsible for checking the required version for each change to apply. The Magento installation only knows that a module has an upgrade script, not what versions it affected. That procedure is called _migration setup_ or _migration scripts_. @@ -76,9 +76,9 @@ Attribute | Description A `table` node can contain three types of subnodes: -* `column` -* `constraint` -* `index` +* `column` +* `constraint` +* `index` #### `column` subnode @@ -192,6 +192,9 @@ Attribute | Description `referenceColumn`| A column in the `referenceTable` `onDelete` | Foreign key trigger. The value must be `CASCADE`, `SET NULL`, or `NO ACTION` +{: .bs-callout-info } +To keep entities identifiers as immutable values the declarative schema does not support `ON UPDATE` action for constraint. + Example: ```xml @@ -437,7 +440,7 @@ It is possible to drop a foreign key only if it exists in the `db_schema_whiteli In this example, Module A defines a new table with primary key `id_column`. Module B declares its own schema, in which it creates a new column (`new_id_column`) and changes the primary index to this column. Module B disables the original primary key and sets a new primary key with a `referenceId` value that is different from PRIMARY. Although this value is different, the real name of the primary key in the database remains PRIMARY. - **Module A declaration** +**Module A declaration** ```xml ``` - **Module B declaration** +**Module B declaration** ```xml Date: Mon, 21 Oct 2019 14:42:16 -0500 Subject: [PATCH 2/3] Grammar fix. --- guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md index 373e223a6f6..57f4e31c5c7 100644 --- a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md +++ b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md @@ -193,7 +193,7 @@ Attribute | Description `onDelete` | Foreign key trigger. The value must be `CASCADE`, `SET NULL`, or `NO ACTION` {: .bs-callout-info } -To keep entities identifiers as immutable values the declarative schema does not support `ON UPDATE` action for constraint. +To keep entity identifiers as immutable values, the declarative schema does not support `ON UPDATE` action for `constraint`. Example: From ea09bc968083b860c1aaa039686ae523fb22a6a2 Mon Sep 17 00:00:00 2001 From: Donald Booth Date: Wed, 23 Oct 2019 10:54:27 -0500 Subject: [PATCH 3/3] Fixed linting errors. --- .../declarative-schema/db-schema.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md index 57f4e31c5c7..02fd1328905 100644 --- a/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md +++ b/guides/v2.3/extension-dev-guide/declarative-schema/db-schema.md @@ -5,9 +5,9 @@ title: Configure declarative schema Before Magento 2.3, extension developers were required to write code (PHP scripts) to change the database schema. The following types of scripts existed before Magento 2.3: -* InstallData and InstallSchema scripts, which are executed the first time a module is installed. -* UpgradeData and UpgradeSchema incremental scripts, which supplement an existing module schema. -* Recurring scripts, which are executed each time you install or upgrade Magento. +* InstallData and InstallSchema scripts, which are executed the first time a module is installed. +* UpgradeData and UpgradeSchema incremental scripts, which supplement an existing module schema. +* Recurring scripts, which are executed each time you install or upgrade Magento. Each script iteratively adds changes. During the installation process, upgrade scripts apply only those changes that have not been applied yet. For example, if you have a module with version 2.1.8 installed and the latest version is 2.1.11, then the upgrade script changes for 2.1.9, 2.1.10, and 2.1.11 will be applied, in order, when you upgrade to 2.1.11. Each upgrade script is responsible for checking the required version for each change to apply. The Magento installation only knows that a module has an upgrade script, not what versions it affected. That procedure is called _migration setup_ or _migration scripts_. @@ -76,9 +76,9 @@ Attribute | Description A `table` node can contain three types of subnodes: -* `column` -* `constraint` -* `index` +* `column` +* `constraint` +* `index` #### `column` subnode