Implementing Incremental Parent-Child Operation

To support incremental parent-child operations, each child row has an opcode, that is, an extra ADB_OPCODE field that is added to the child schema. The ADB_OPCODE_BYPASS field is used to bypass the current table operation. The adapter determines if the operation is an incremental parent-child operation by checking the first level child opcode. If the first level child opcode is not set, the adapter treats it as a complete operation. For the subsequence child level, if the child opcode is not set, the child opcode inherits the parent opcode.

Mixed parent-child operations are also supported. You can send a message to insert new child rows, update other child rows, and delete other child rows for an existing parent-child object.
Note: When Publication Service works with parent and child tables, the value of the ADB_OPCODE field in the parent table and that in the child table must be the same. Or you can just set the value of the ADB_OPCODE field in the parent table and leave ADB_OPCODE field in the child table empty.
The following example shows a mixed parent-child operation. 
adb.key
{
RVMSG_INT 2 ^type^ 1
RVMSG_INT 2 ^pfmt^ 10
RVMSG_INT 2 ^ver^ 30
RVMSG_INT 2 ^encoding^ 1
RVMSG_RVMSG 110 ^prefixList^
{
RVMSG_STRING 49 1
"/tibco/public/sequence/ae/class/ae/ADB/abc"
RVMSG_STRING 37 default "/tibco/public/class/ae/ADB/abc"
}
RVMSG_RVMSG 77 ^tracking^
{
RVMSG_STRING 30 ^id^ "Gi2--4--DGMSk--s-064zzw8L-zzw"
RVMSG_STRING 22 ^1^ "adb.key"
}
RVMSG_RVMSG 1200 ^data^
{
RVMSG_STRING 8 ^class^ "S_KEYP1"
RVMSG_INT 4 ADB_OPCODE 10
RVMSG_RVMSG 480 ADB_SEQUENCE_S_KEYP2
{
RVMSG_STRING 18 ^class^ "sequence[S_KEYP2]"
RVMSG_INT 4 ^idx^ 1
RVMSG_RVMSG 210 ^1^
{
RVMSG_STRING 8 ^class^ "S_KEYP2"
RVMSG_INT 4 ADB_OPCODE 10
RVMSG_RVMSG 119 ADB_SEQUENCE_S_KEYP3
{
RVMSG_STRING 18 ^class^ "sequence[S_KEYP3]"
RVMSG_INT 4 ^idx^ 1
RVMSG_RVMSG 58 ^1^
{
RVMSG_STRING 8 ^class^ "S_KEYP3"
RVMSG_INT 4 ADB_OPCODE 4
RVMSG_REAL 8 A 1
RVMSG_STRING 2 B "a"
RVMSG_REAL 8 C 4
}
RVMSG_RVMSG 58 ^2^
{
RVMSG_STRING 8 ^class^ "S_KEYP3"
RVMSG_INT 4 ADB_OPCODE 3
RVMSG_REAL 8 A 1
RVMSG_STRING 2 B "a"
RVMSG_REAL 8 C 4
}
}
}
RVMSG_RVMSG 210 ^2^
{
RVMSG_STRING 8 ^class^ "S_KEYP2"
RVMSG_INT 4 ADB_OPCODE 1
RVMSG_REAL 8 A 2
RVMSG_STRING 2 B "a"
RVMSG_REAL 8 C 4
RVMSG_RVMSG 119 ADB_SEQUENCE_S_KEYP3
{
RVMSG_STRING 18 ^class^ "sequence[S_KEYP3]"
RVMSG_INT 4 ^idx^ 1
RVMSG_RVMSG 58 ^1^
{
RVMSG_STRING 8 ^class^ "S_KEYP3"
RVMSG_REAL 8 A 2
RVMSG_STRING 2 B "a"
RVMSG_REAL 8 C 4
}
}
}
}
}
}
When the adapter receives this message, it performs the following database operations in sequence:
  1. Bypass the parent table operation.
  2. Bypass the first row operation on the S_KEYP2 child table.
  3. UPDATE S_KEYP3 set B = 'a', C = 4 where A = 1;
  4. DELETE FROM S_KEYP3 where A = 1;
  5. INSERT INTO S_KEYP2 (A, B, C) values (2, 'a', 4);
  6. INSERT INTO S_KEYP3 (A, B, C) values (2, 'a', 4);

Changing the Publication Trigger to Publish a Subset of Rows

You can set up a publication to publish only a subset of rows within a table. That is, there may be scenarios where it is desirable to publish only if the inserted, deleted, or updated row satisfies certain conditions. It is possible to use the callout library to do this additional filtering. It is simpler and more efficient to use a trigger that directly tests whether publishing conditions are met.

For Oracle, add a when clause to a row level trigger to test for the desired conditions. For Sybase and Microsoft SQL Server, use the if statement within a trigger body to test for the desired conditions.

For example, you can change the demo1_ora.sql trigger to fire only if the ORDER_PRICE value is $1.00 or greater:

CREATE OR REPLACE TRIGGER TRI_P_ORDER_TABLE AFTER INSERT OR UPDATE OR DELETE ON ORDER_TABLE FOR EACH ROW WHEN (new.ORDER_PRICE >= 1.00)

Contents
Search Results