WL#16617: Implement DML for Json Duality View
This WL aims to implement DML operations on JSON Duality View.
JSON duality views can be created on a single or multiple base table. Refer WL#16616 for DDL statements on JSON duality view and Create Rules. The DML operations (INSERT, UPDATE and DELETE operation) on JSON duality view encompass the following steps,
Validation of input JSON document: This step should ensure that JSON document is syntactically valid. Subsequently, it should also verify that the input JSON document adheres to the schema of the JSON document produced by the JSON duality view.
Sub-statement Generation: This step should generate an equivalent sub-statement from the provided input JSON document.
Example: If a JSON duality view is defined on a student base table, then
INSERT INTO dv1 VALUES ( ' { "_id" : 1, "name" : "Manu", "department" : "Computer Science" } ' );
Should internally generate INSERT statement on student able as below,
INSERT INTO student VALUES(1, "Manu", "Computer Science");
Note: INSERT and UPDATE statements on duality view can lead to multiple INSERT, UPDATE and DELETE statements on base tables of a duality view.
Order of statement execution: This step should determine the order of sub-statement execution. For instance, If a JSON duality view is defined on the tables linked by referential integrity constraint, then the INSERT operation on the child table should precede the INSERT operation on the parent table.
Execution of sub-statements: This step should execute sub-statements generated and sequenced as part of the main DML statement on view. Transaction semantics must be maintained.
DML statement execution on a JSON duality view should be atomic. MDL locking and Row locking semantics must be consistent. Sub-statements events logging for replication must be consistent.
1. Prerequisites for all DML operations.
The user must be granted all required privileges on the duality view and its associated base tables.
JSON Duality view must syntactically and semantically valid
FR1.1: An error must be generated if aforementioned requirements are not met.
FR1.2: DML functionality on duality view must be available only in the Enterprise version of MySQL. DML operations on duality view in Community Code, must report an error.
2. Requirement for input JSON document for DMLs.
FR2.1: The input for DML operations must accept only valid JSON document.
The input JSON document for DML operations must be validated to make sure it matches to the schema of a JSON document generated by the JSON duality view.
3. Requirement for Table Annotations
3.1 INSERT operation requirements
FR3.1.1: If a new object should be inserted, then the Root object and Sub-objects of a document must have INSERT annotation.
FR3.1.1.1: If INSERT annotation is not specified, then an error must be reported.
FR3.1.1.2: If sub-objects already exists and it just referenced in the object being inserted, then annotation check must not be done.
FR3.1.2: If a sub-object is updated as part of an INSERT operation, then the sub-object must have UPDATE annotation.
FR 3.1.2.1: If UPDATE annotation is not specified, then sub-object must be just referred and changes to it must be ignored.
FR3.1.3: If a referenced sub-object does not exist, then an error must be reported.
3.2 UPDATE operation requirements
FR3.2.1: If root object and sub-objects should be updated, then objects of a document must have UPDATE annotation.
FR3.2.1.1: If UPDATE annotation is not specified, then an error must be reported.
FR3.2.2: If sub-object is just referenced, then annotation check must not be done. Only existence of sub-object must be checked.
FR3.2.3: If sub-object is modified and UPDATE annotation is not specified, then only existence of sub-object must be checked. It should not report an error for missing annotation.
FR3.2.4: If a sub-object should be replaced with an another existing sub-object in table, then annotation check must not be done.
FR3.2.5: If a sub-object is inserted as part of an UPDATE operation, then the object must have INSERT annotation.
FR3.2.5.1: An error must be reported for missing INSERT annotation.
FR3.2.6: If a referenced sub-object does not exist, then an error must be reported.
FR3.2.7: If sub-object is a nested descedent and element of object is deleted, then the sub-object must have a DELETE annotation.
FR3.2.7.1: If DELETE annotation is not specified, then an error must be reported.
3.3 DELETE operation requirements
FR3.3.1: If root object must be deleted, then an object of a document must have a DELETE annotations.
FR3.3.1.1: If DELETE annotation is not specified, then an error must be reported.
FR3.3.2: A singleton sub-object must not be deleted.
FR3.3.3: Nested sub-object must not be deleted if DELETE annotation is not specified.
FR3.3.3.1: If sub-object has DELETE annotation, then all elements of nested sub-object must be deleted.
4. Requirement for Sub-statement Generation.
Note: It is assumed that objects have required Table level annotations here.
4.1 INSERT operation requirements
FR4.1.1: Inserting NULL value must report an error.
FR4.1.2: Inserting empty object must report an error.
FR4.1.3: Insert operation resulting in any constraint (NULL, Primary Key, Unique Key, Check constraint and Foreign Key constraint) violation must report an error.
FR4.1.4: Value for primary key columns must be specified for Insert operation. There is a possibility deducing primary key column value from JOIN condition. Kindly check 4.1.7. If value can be generated then, input without primary key column value is allowed.
FR4.1.4.1: If Primary Key columns are missing (and if they can not be deduced from JOIN condition too) then an error must be reported.
FR4.1.5: Insert operation must permit the omission of values for non-primary key columns.
FR4.1.5.1: Either NULL or DEFAULT value is stored for those columns.
FR4.1.6: If values columns used in the JOIN condition of Object and sub-object are specified, then values of columns used in the JOIN condition must be same (i.e. JOIN condition must be specified).
FR4.1.6.1: An error must be reported otherwise.
FR4.1.7: If a value for a column is not specified and it is part of a sub-object's JOIN condition, then value from other operand must be used for it.
In the following example, value for column t2.f3 is not specified in the INSERT statement. t2.f3 is used in the join condition of "ChildNode" and value for t1.f1 is specified. In this case for t2.f3 must be copied from the t1.f1 (3).
CREATE TABLE t1 (f1 INT PRIMARY KEY, f2 INT);
CREATE TABLE t2 (f3 INT PRIMARY KEY REFERENCES t1(f1), f4 INT);
INSERT INTO t1 VALUES (1, 2);
INSERT INTO t2 VALUES (1, 200);
CREATE OR REPLACE JSON DUALITY VIEW dv1 AS
SELECT JSON_DUALITY_OBJECT(
WITH(INSERT, UPDATE, DELETE)
"_id" : f3,
"f4" : f4,
"ChildNode" , (SELECT JSON_DUALITY_OBJECT (
WITH(INSERT, UPDATE)
"f1" : f1,
"f2" : f2
) FROM t1 WHERE t1.f1 = t2.f3)
) FROM t2;
INSERT INTO dv1 VALUES (' { "f4" : 400,
"ChildNode" : { "f1" : 3, "f2" : 4 } } ');
-- By view definition, columns use in join_condition should match. So in this case, value for "t1.f1" should be copied from the "t2.f3".
FR4.1.8: If value for both the columns used in the JOIN condition are not specified then an error must be reported.
FR4.1.9: If column used in JOIN condition is not projected in the JSON duality view, then the value for the non-projected column must be copied from other column used in the JOIN condition. Similar to 4.1.7
FR4.1.10: For an object, not specifying complete sub-object must be allowed if
a) Rows matching join condition already existing in the sub-object's table
b) Or skipping sub-object INSERT does not voilate any table constraints.
FR4.1.11: If a Root object being inserted just references already existing sub-objects, then only Root object must be inserted. No errors should be reported for sub-objects.
FR4.1.12: If a Root object being inserted just references only few existing sub-objects, then only Root object must be inserted. Sub-objects which are not specified must not be deleted.
FR4.1.13: If a Root object being inserted references already existing sub-objects and modifies some non-primary columns, then Root object must be inserted, and sub-objects must be updated.
FR4.1.14: If object or sub-object is defined on the same table at any level of JSON duality view definition, values for the columns must be same.
FR4.1.14.1: If values are not same, then an error must be defined.
FR4.1.15: Inserting object for JSON duality view on self referencing table must be supported.
FR4.1.16: Inserting object for JSON duality view on circular referencing table must be supported.
FR4.1.17: Multi-object insert must be rejected in V1.
4.2 UPDATE operation requirements
FR4.2.1: Updating JSON objects to NULL value must report an error.
FR4.2.2: Updating JSON objects to empty object must report an error.
FR4.2.3: UPDATE operation resulting in any constraint (NULL, Primary Key, Unique Key, Check constraint and Foreign Key constraint) failure must report an error.
FR4.2.4: UPDATE operation must not update primary key column values of Root and sub-objects.
FR4.2.4.1: An error must be reported if primary key column value for existing objects being updated or missing.
FR4.2.5: For UPDATE operation, all projected column values must be specified.
FR4.2.5.1: If any column values is missing, then an error must be reported.
Note: if sub-object or element(s) in sub-object is missing,
then it is deleted. Kindly refer 4.2.10.
Error is not generated for this case.
FR4.2.6: If object and sub-object columns are not modified , then base tables must not be updated.
FR4.2.7: If object is modified and sub-object columns are not modified, then only object's base table must be updated. Sub-object's tables must not be updated.
FR4.2.8: If both object and sub-object columns are modified, then base tables of both the objects must be updated.
FR4.2.9: If new sub-object is inserted, then new row must be inserted in the sub-object's table.
FR4.2.10: If an existing sub-object(s) is missing (deleted), then the row(s) for sub-object must be deleted.
FR4.2.11: If deletion of object results any table constraint violation, then an error must be reported.
FR4.2.12: If sub-object is replaced with an existing sub-object in the base table, then replacement must be allowed.
FR4.2.13: If multiple sub-objects are projected from the same table, then same value must be specified for all such sub-objects.
FR4.2.14: Multi-object update must be rejected in V1.
FR4.2.15: If ETAG supplied for UPDATE operation does not match the ETAG generated for the same object, then an error must be reported.
4.3 DELETE operation requirements
FR4.3.1: Multi-object delete must be rejected in V1.
FR4.3.2: Deleting object must report an error if referential constraint fails.
FR4.3.3: Sub-objects must be deleted if they are nested elements.
FR4.3.3.1: If a sub-object is a singleton object, then it must not be deleted.
5. Requirement for Sub-statement execution.
FR5.1: Generated statements for DML operation on JSON duality view, must be executed as sub-statement of a DML operation on view.
FR5.2: Sub-statement execution must not acquire new MDL locks or row locks.
FR5.3: If any sub-statement execution fails, then all sub-statements must be rolled back.
6. Requirement for Auto-increment column projection.
FR6.1: If column with auto-increment attribute is projected, then for DML operations value for the column must be specified explicitly.
FR6.1.1: If not specified, then column value must be deduced from the join condition. Otherwise, an error must be reported.
7. Requirement for triggers on base-tables.
FR7.1: If triggers are defined on the base-tables of a JSON duality view, then for all the generated sub-statement execution, triggers of respective events must be executed.
8. Requirement for Referential actions.
FR8.1: If base tables of JSON duality view are linked by refenetial constraint, then sub-statement execution must execute foreign key referential actions if defined any.
FR8.2: An error must be reported if foreign key cascading operation fails.
9. Requirement for DML statements.
FR9.1: INSERT statement clauses HIGH_PRIORITY, DELAYED must not be allowed for JSON duality views.
FR9.2: INSERT ... ON DUPLICATE KEY UPDATE statement must not be allowed for JSON duality views.
FR9.3: INSERT ... SELECT statement must not be allowed for JSON duality views.
FR9.4: Clause LOW_PRIORITY and IGNORE in INSERT, UPDATE and DELETE statements must not be allowed for JSON duality views.
FR9.5: Multi-table UPDATE and DELETE must not be allowed for JSON duality views.
FR9.6: INSERT, UPDATE and DELETE statements on SQL view defined over JSON duality view must not be allowed.
FR9.7: LOAD statement on JSON duality view must not be allowed.
FR9.8: REPLACE statement must not be allowed for JSON duality views.
10. Requirement for Performance Schema Instrumentation.
FR10.1: DML operation on JSON duality view and sub-statement execution must be instrumented.
11. Requirement for Replication
FR11.1: DML operation on JSON duality view and sub-statements of it must be replicated consistently.
FR11.1.1: if execution any sub-statement fails, then other sub-statements must not be replicated.
12. Requirement for Daigonstics_area
FR12.1: Error from sub-statement execution must be stored in the Diagnostics_area for error reporting.
FR12.2: Warnings from all sub-statements execution must be stored in the Diagnostics_area.
FR12.3: Number of affected rows in the base table by all sub-statement for a JSON object must be stored in a Diagnostics_area.
1. Introduction:
DML operations on JSON duality views differ from those on base tables and standard SQL views. They follow a multi-step process. Each DML operation performs minimal checks and then delegates execution to specialized single-entry functions for JSON duality views.
The DML on JSON duality view involve the following steps:
- Validation
- Sub-statement generation
- Order of statements execution
- Sub-statement execution
For discussion assuming all possible permission tags have been provided.
1.1 Validation:
In the MySQL server, an input JSON document is validated to ensure its syntactic correctness. Upon successful validation, internally document is represented using an n-ary tree of Json_dom objects. Each node within this tree can be a composite object like Json_object or Json_array or a literal such as Json_number or Json_string.
Internally, even a JSON Duality view is represented as an n-ary tree. Each node in this tree describes a JSON object, containing information such as: the corresponding base table, attribute mappings to the base table's columns, attribute mappings to nodes in sub-trees, the node's type (e.g., singleton descendant or nested (array) descendant), and other relevant details.
For validation input document is not compared with JSON schema. Instead, the following algorithm is used for validation.
The basic algorithm for matching an input JSON document to the schema of a document generated from the view is as follows:
Pair all the attributes of the Json_object from the n-ary tree of Json_dom objects with the correpsonding node in the n-ary tree of JSON duality view.
Unpaired attributes in the Json_object results in an error.
Unpaired attribute in JSON duality view node are OK.
- In INSERT operation, NULL or DEFAULT values are used for columns of such attribute.
- In UPDATE operation, the existing value for a column is used.
- If JSON duality view node has children then the same matching process must be repeated for each child.
- For singleton descendant, Json_dom should be actual Json_object.
- For nested descendant, Json_dom will be Json_array. Each element of an array should be actual Json_object. The matching process is repeated for each element of an array in this case.
- For singleton descendant, Json_dom should be actual Json_object.
1.2 Sub-statement generation:
During the validation step, a vector is prepared, containing:
For INSERT & DELETE operations: A JSON duality view node and corresponding Json_object from Json_dom.
For UPDATE operation: A JSON duality view node, corresponsing Json_object from input document (new value) and Json_object prepared from the base-tables (existing value).
In this step, sub-statement on base tables of view are generated using the vector.
1.2.1 Sub-statement generation for INSERT operation:
The basic algorithm for generating sub-statement on each element of vector during the INSERT operation is as follows:
An INSERT statement for object is generated using the table name and column names obtained from the Duality view node.
a. Column values are populated from the Json_dom object.
b. If the value for a column involved in a JOIN condition is missing, it is attempted to be filled from the other operand (child or parent object's column) of the JOIN condition.
b.1. If values for both operands of the JOIN condition are missing, an error is reported.
b.2. If values for the column used in the JOIN condition are provided but do not match, an error is also reported.
If an object is singleton or nested descendant, check if corresponding rows already exist in the base table.
a. If exists, then match input column values with corresponsing row values.
a.1. If matches, then sub-statement is not generated.
a.2. If some columns values are changed, then an UPDATE statement is generated using the table name and column names obtained from the corresponding Duality view node.
b. If it does not exist, then INSERT statement generation process (step1) is repeated for the descendant object.
b.1. For nested descendant, INSERT statement generation process (step1) is repeated for each input element.
1.2.2 Sub-statement generation for UPDATE operation:
The basic algorithm for generating sub-statement on each element of vector during the UPDATE operation is as follows:
An UPDATE statement for object is generated using the table name and column names obtained from the Duality view node.
a. Column values are populated from the Json_dom object.
b. If the value for a column involved in a JOIN condition is missing, it is attempted to be filled from the other operand (child or parent object's column) of the JOIN condition.
b.1. If values for column used in the JOIN condition are specified, and if they do not match then an error is reported.
c. If values for some columns are missing, then it is OK. Column values are not modified in this case.
If an object has a singleton descendant, check if a corresponding row exists in the base table.
a. If exists, then match input column values with row values.
a.1. If matches, then sub-statement is not generated.
a.2. If some columns are changed, then an UPDATE statement is generated using the table name and column names obtained from the corresponding Duality view node.
b. If it does not exists, then an INSERT statement is generated.
b.1. For INSERT statement, values for columns will be filled as mentioned in step 1.a.
If an object has nested descendant, then check for all matching rows corresponding element in array is listed,
a. If listed, then repeat process of generating statements for child object.
b. If not listed, then generate DELETE statement.
1.2.3 Sub-statement generation for DELETE operation:
The basic algorithm for generating sub-statement on each element of vector during the DELETE operation is as follows:
DELETE statement is generated using table name information from Duality view node.
If object has children, then for each child DELETE statement is generated using table name information from corresponding Duality view node.
1.3 Order of statements execution
This step determines the order in which sub-statements should be executed. For example, if a JSON duality view is defined on tables linked by a referential integrity constraint, then the INSERT operation on the child table must precede the INSERT operation on the parent table.
Each node within the n-ary tree of the JSON duality view stores its object type (root, singleton, or nested). This information is used for determining the order of sub-statement execution (dependency weight is calculattion) during Data Manipulation Language (DML) operations.
The basic algorithm of depedency weight calculation or order of sub-statement handling is as follows:
The root object always receives a weight of "0" at first.
If the child is singleton object, then child gets weight "+1" higher than the parent object.
a. This is because a singleton child, often representing a primary key table, must be inserted before its child in a foreign key table.
If the child is nested object, then child gets weight "-1" lower than the parent object.
a. This is because a nested child, often representing a foreign key table, must be inserted after its parent in a primary key table.
If child object has children, then the process of dependency weight calculation is repeated for each child.
At the end, objects are sorted on weight bases in ascending order.
a. The statement with the lowest weight is executed first for INSERT and UPDATE operation on duality view.
b. Order is revered for the DELETE operation on duality view.
For example the JSON duality view "driver_dv" defined as below,
CREATE TABLE team (
team_id INT PRIMARY KEY,
name VARCHAR(255),
points INT NOT NULL
);
CREATE TABLE driver (
driver_id INT PRIMARY KEY,
name VARCHAR(255),
points INT NOT NULL,
team_id INT NULL,
FOREIGN KEY (team_id) REFERENCES team(team_id)
);
CREATE TABLE race (
race_id INT PRIMARY KEY,
name VARCHAR(255),
laps INT NOT NULL,
race_date DATE
);
CREATE TABLE driver_race_map (
driver_race_map_id INT PRIMARY KEY,
race_id INT NOT NULL,
driver_id INT NOT NULL,
position INT NOT NULL,
CONSTRAINT driver_race_map_uk UNIQUE (race_id, driver_id),
FOREIGN KEY (race_id) REFERENCES race(race_id),
FOREIGN KEY (driver_id) REFERENCES driver(driver_id)
);
CREATE JSON DUALITY VIEW driver_dv AS
SELECT JSON_DUALITY_OBJECT(
WITH(INSERT, UPDATE)
'_id' : driver.driver_id,
'name' : driver.name,
'points' : driver.points,
'team', (
SELECT JSON_DUALITY_OBJECT(
WITH(INSERT,UPDATE)
'team_id' : team.team_id,
'name' : team.name,
'points' : team.points
)
FROM team WHERE driver.team_id = team.team_id
),
'race_details', (
SELECT JSON_ARRAYAGG(
JSON_DUALITY_OBJECT(
WITH(INSERT, UPDATE)
'driver_race_map_id' : driver_race_map.driver_race_map_id,
'position' : driver_race_map.position,
'race', (
SELECT JSON_DUALITY_OBJECT(
WITH(INSERT, UPDATE)
'race_id' : race.race_id,
'name' : race.name,
'laps' : race.laps,
'race_date' : race.race_date
)
FROM race
WHERE driver_race_map.race_id = race.race_id
)
)
)
FROM driver_race_map
WHERE driver_race_map.driver_id = driver.driver_id
)
)
FROM driver;
for DML operations on "drivers_dv" sub-statements order of execution with dependecy weight is generated as below,
Attribute, base_table, depedency_weight
("team", "test.team", -1)
("Root Node", "test.driver", 0)
("race", "test.race", 0)
("race_details", "driver_race_map", 1)
The execution order of sub-statements is as follows: "team", then "Root node" and "race", and finally "race_details".
1.4 Sub-statements execution:
This step executes the generated and ordered sub-statements. All sub-statements must be executed within the context of the main DML statement on the duality view. Currently, only statements within Stored Functions and Triggers are executed as sub-statements. Furthermore, within Stored Functions and Triggers, statements are prepared, and MDL (Metadata Locks) and THR Locks are acquired during the pre-locking phase. However, currently, a framework for executing SQL statements in string format as sub-statements with proper transaction semantics is not readily available.
To execute statements generated for DML operations on duality views, a new execution model is introduced. This model executes statements within context of main DML statement similar to Stored Function and Triggers. The basic algorithm for this model is as follows:
Push new Diagnostics_area(DA) instance. Backup caller DA.
Backup open tables and reset open tables state.
a. Duality view and all base tables opened as part of view open process are saved and state is reset.
Set sub-statement execution mode. New sub-statement mode "SUB_STMT_DUALITY_VIEW" is introduced.
a. This make sure sub-statement execution maintains transaction semantics.
i. If any sub-statement exection fails, then affect of all other executed sub-statements is rolled back and none of the statements events are logged to binlog.
Each sub-statement is exected using Regular_statement_handle interface.
a. Regular_statement_handle takes statement in SQL string form as input.
b. Since sub-statements operate on tables for which MDL and THR locks were acquired during the duality view's pre-locking stage, no new MDL or THR locks are acquired during sub-statement execution. Clauses like LOW_PRIORITY and HIGH_PRIORITY, which can influence the type of MDL lock request within a sub-statement, are currently restricted for duality views
c. Successful execution of sub-statement, creates binlog event but they are flushed at main DML statement end (only if all sub-statements execution is successful).
If execution of sub-statement fails, then copy error from DA to caller DA.
If execution of sub-statement succeeds, then copy warning (if any) from DA to caller DA.
Reset sub-statement execution mode.
Reset open table state.
a. Only open table state is reset but open tables backup from 2) are not restored. Restoring backup tables closes the tables opened in the 4) and MDL locks are released. Since, sub-statements in 4) try to open tables which are already opened as part of main duality view open. No new MDL locks are acquired. Locks are acquired for main statements itself are used. Closing tables at this stage will release all MDL locks. Hence backup tables are not restored.
Restore DA state to caller DA.
This model ensures that sub-statements are executed while maintaining transaction semantics.
2. Future Work:
Multiple JSON object INSERT, UPDATE and DELETE is not supported in Version1.
Auto-increment column projection is supported but populating generated value is not supported. In future versions, a complete Auto-increment feature will be supported.
Complete table and column tag support: In Version1, DML operations only with all flags are supported.
LOW_PRIORITY and IGNORE clauses DML statements for JSON duality views are restricted in Version1.
HIGH_PRIORITY clause in INSERT statement is restricted in Version1.
ORDER BY and LIMIT clause in UPDATE and DELETE statements are restricted in Version1.
EXPLAIN statement on DML not supported in Version1.
REPLACE statement duality view is not supported in Version1.
Column list in INSERT statement for duality view is not supported in Version1.
3. Restrictions:
- LOAD statement on JSON duality view will not be supported.
- INSERT ... FROM SELECT is not supported on JSON duality views.
- Multi-table UPDATE and DELETE will be restricted for JSON duality views.
- INSERT ... ON DUPLICATE KEY UPDATE will be restricted for JSON duality views.
4. Replication:
This feature does not have any impact on replication.
4.1 What are the Replication/High-Availability considerations with respect to deployment and installation? **
4.1.1 Are there extra steps needed to install the feature? Ans: No extra steps are required for the installation of the feature.
4.1.2 Is there a specific order for those steps? For instance, need to be installed first on replica servers and only then on source servers. Ans: No special order needed for feature installation. Regular order of installation can be followed. First, the replica servers should be upgraded to the version that supports JSON DUALITY VIEWS. After the replicas have been successfully upgraded, the source server can then be upgraded. This order is important to prevent the source from replicating statements that are not supported on the older version of the replica servers.
4.2 How does the feature operate on distributed environment?
4.2.1 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? Ans: 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.
4.2.2 Does the feature rely on session configuration? Does that session configuration need to be replicated together with data? Ans: 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.
4.3 Upgrade/Downgrade and Cross-Version Replication
4.3.1 Any impact on cross-version replication? Which? Ans: There is no impact on cross-version replication. For NEW-->OLD replication setup, DDLs to CREATE/ALTER itself fails on replica.This is expected for any new feature introducing syntax level changes. For NEW-->OLD replication setup, DML operations fails if binlog format is statement type (this type is deprecated now). With row-based binlogging, events on base tables are replicated. Hence, changes are applied on the replica.
4.3.2 Any impact on upgrade/downgrade? Which? Ans: There is no impact on the upgrade or downgrade process. On older versions, view definition using JSON_OBJECT() is considered as read-only. Hence DML on such view is not allowed.
4.3.3 What about rolling upgrades? How is the user able to do rolling upgrades? Ans: There is no impact on the rolling update.
4.4 Behavior Change
4.4.1 Is there anything the user could do before the worklog, which has a different effect after the worklog? Ans: There is no such behavior. Actions taken by the user before the worklog will have the same effect after the worklog.
4.4.2 Is there anything the user could do before the worklog, which cannot be done after the worklog? Ans: There is no such behavior. All actions that can be performed by the user before the worklog can also be performed after the worklog. There's no such behaviour.