|
Factor
|
Applies to default write mode?
|
Applies to distributed write mode
|
|---|---|---|
|
Client application must execute operations by using the grid-aware database driver.
|
Yes.
If, instead, a client application makes a direct database connection to a particular grid node, all operations can run only on the local node. If any operation attempts to write to a row where the primary replication unit of the partition for the row is not on the local node, that operation fails.
|
Yes.
|
|
Operations that execute directly inside a particular node must not attempt to write to a row where the primary replication unit of the partition for the row is not on the local node.
|
Yes.
For example, write operations inside triggers or statements inside stored procedures can only write to a row if the primary replication unit of the partition for that row is on the local node.
|
No.
Operations can write to the row if you switch the grid to distributed write mode before executing the write operation in the trigger or stored procedure.
However, if the operation also includes SELECT statements, the transaction will fail.
|
|
Each statement writes to rows where the primary partitions are all in the same node.
|
Yes,
An operation is routed to the node that contains the primary replication unit for the partition of the first row that is affected.
If, within the same transaction, an operation attempts to write to a row that is in a different node, the particular operation fails with an error code, but the transaction continues. Subsequent write operations to the first node can be completed.
|
No.
One transaction can write to rows where the primary partitions are in different nodes if you switch the grid to distributed write mode before executing the write operation.
However, if the transaction also contains SELECT statements, the transaction will fail.
|
|
Transactions can update the partitioning key columns of a partitioned table.
|
No.
However, you can achieve the same effect by deleting the existing row and inserting a new row with the same data and the updated partitioning key.
The DELETE and INSERT operations should be executed in separate transactions in case the new row is inserted into the primary replication unit for a partition that resides on a different node to the original row.
|
No.
|
|
Partitioning key columns are defined in the WHERE clause of the DML statement.
|
Yes.
The driver can then identify the node that contains the primary replication unit for the partition of the affected row.
|
No.
The distributed write functionality determines the primary replication unit for the partition of the affected row.
|
|
Literal values are not used for binding values to DML partitioning key columns.
|
Yes.
Instead, the application must use dynamic parameter binding, and bind partitioning key columns by using the ‘?’ parameter marker, see Use dynamic parameter binding in statements.
|
Yes.
|
|
Only the equal ‘=’ constraint is used in the WHERE clause for DML operations.
|
Yes.
For example, you cannot use the following statement because it defines a range:
DELETE FROM TAB1 WHERE I >= 10;
|
No.
This limitation can be addressed by switching the grid to distributed write mode before executing the write operation.
|