The JSON Duality View feature is available in all MySQL editions. DDL operations (CREATE, ALTER, DROP) on JSON Duality Views, as well as related operations through INFORMATION_SCHEMA tables and SHOW statements on JSON Duality view, are supported across all MySQL editions.However, DML operations (INSERT, UPDATE, DELETE) on JSON Duality Views are only supported in MySQL Enterprise Edition and MySQL cloud servers for now.DML operations on JSON Duality Views are not supported in the MySQL Community Server.

This WorkLog aims to enable support for DML operations on JSON Duality Views in the MySQL Community Server.

Source Code

• FR S.1: DML source must be located in sql/json_duality_view/dml.cc
• FR S.2: sql/CMakeLists.txt must build community edition with dml
• FR S.3: Unused error codes/messages must be obsoleted

Tests

• FR T.1: mysql-test/suite/jdv/t/jdv_ddl.test must be removed.
• FR T.2: All test files must be moved to mysql-test/suite/jdv/t
• FR T.3: Test file names and comments must not contain 'demo'
• FR T.4: Test must not have test cases that are commented out
• FR T.5: There must be no .inc files for checking DML

Source Code

JSON Duality view DML source code is not located in sql/json_duality_view/dml.cc. By moving DML related changes to sql/json_duality_view the DML source code will be part of the Community Server. The moved dml.cc replaces community dml.cc which returned error messages for all DML operations. By removing the community dml.cc there is no longer any use of the error code ER_JDV_FEATURE_EDITION_LIMIT so this needs to marked as obsolete.

Build System

The build system files must be updated to reflect the file path changes. The special handling of dml.cc in sql/json_duality_view must be removed and all the JDV code be build in the normal way.

Tests

All tests JSON Duality view tests must be moved to mysql-test/suite/jdv. Additionally the wl will:

• Remove jdv_ddl.test currently in the jdv suite.
• Move jdv_option_tracking.test to the option_tracking suite.
• Rename tests with 'demo' in the name.
• Enable and modify as needed any commented test cases.
• Remove include/not_have_jdv_dml.inc and include/have_jdv_dml.inc as they are no longer needed.
• Add/remove Copyright headers as appropriate for all JDV-related tests.

CI / PB2

Since jdv_tests test suite is removed, collection files referencing it must be updated. The jdv suite is part of the default set of suites run by mtr.

Replication

What are the Replication/High-Availability considerations with respect to deployment and installation?

• Are there extra steps needed to install the feature?

  No extra steps are required for the installation of the feature.

• Is there a specific order for those steps? For instance, need to be installed first on replica servers and only then on source servers.

  No.

How does the feature operate on distributed environment?

• Does the feature rely on server local configuration? That is, do source and replica server need to have the same configuration, plugins and or components?

  The feature does not rely on local configurations, whether session or global, nor does it depend on specific plugins or components. Therefore, the source and replica servers do not need to have identical configurations or components for the feature to function properly.

• What is the expected behavior when the configuration does not match?

  NA

• Does the feature rely on session configuration? Does that session configuration need to be replicated together with data?

  The feature does not rely on session configuration. As such, session configuration does not need to be replicated alongside the data, allowing for flexibility in session settings between the source and replica servers.

Upgrade/Downgrade and Cross-Version Replication

• Any impact on cross-version replication? Which?

  There is no impact on cross-version replication.

• Any impact on upgrade/downgrade? Which?

  Upgrade must be possible from a version that did not support FEATURE, to the current version that does. When downgrading from a version that supports FEATURE to one that does not, OPERATION fail on the target version as expected.

• What about rolling upgrades? How is the user able to do rolling upgrades? Please consider LTS and non-LTS for all bullets in this section https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html

  There is no impact on the rolling update.

Behavior Change

• Is there anything the user could do before the worklog, which has a different effect after the worklog?

  Executing DML against JDVs will be possible in community edition. Previously this would result in an error.

• Is there anything the user could do before the worklog, which cannot be done after the worklog?

  There is no such behavior. All actions that can be performed by the user before the worklog can also be performed after the worklog.