5.3 The Event Log Table

The event log table stores publication events. This section discusses the structure and capabilities of the event log table.

You can customize the name of the event log table and its columns to avoid conflicts with reserved database keywords. The order, number, and data types of its columns, however, are fixed. In databases that are unaware of column position, order is determined by the Sort Column Names By parameter. See Sort Column Names By.

Events in this table can be ordered either by order of insertion (the record_id column) or chronologically (the event_time column). Ordering events chronologically allows event processing to be delayed. To order publication events chronologically, set the Enable Future Event Processing parameter to Boolean True. See Enable Future Event Processing?.

5.3.1 Event Log Columns

This section describes columns in the event log table. Columns are ordered by position.

  1. record_id

    The record_id column is used to uniquely identify rows in the event log table and order publication events. This column must contain sequential, ascending, positive, unique integer values. Gaps between record_id values no longer prematurely end a polling cycle.

  2. status

    The status column indicates the state of a given row. The following table lists permitted values:

    Table 5-9 Permitted Values for Status Columns

    Character Value

    Interpretation

    N

    new

    S

    success

    W

    warning

    E

    error

    F

    fatal

    To be processed, all rows inserted into the event log table must have a status value of N. The remainder of the status characters are used solely by the Publisher channel to designate processed rows. All other characters are reserved for future use.

    NOTE:Status values are case sensitive.

  3. event_type

    Values in this column must be between 1 and 8. All other numbers are reserved for future use.

    The following table describes each event type:

    Table 5-10 Event Types

    Event Type

    Interpretation

    1

    insert field

    2

    update field

    3

    update field (remove all values)

    4

    delete row

    5

    insert row (query-back)

    6

    update row (query-back)

    7

    insert field (query-back)

    8

    update field (query-back)

    For additional information on this field, see Section 5.3.2, Event Types.

  4. event_time

    This column serves as an alternative ordering column to record_id. It contains the effective date of the event. It must not be NULL. For this column to become the ordering column, set the Enable Future Event Processing parameter to Boolean True. See Enable Future Event Processing?.

  5. perpetrator

    This column identifies the database user who instigated the event. A NULL value is interpreted as a user other than the driver user. As such, rows with a NULL value or value not equal to the driver’s database username are published. Rows with a value equal to the driver’s database username are not published unless the Allow Loopback Publisher parameter is set to Boolean True. See Allow Loopback?.

  6. table_name

    The name of the table or view where the event occurred.

  7. table_key

    Format values for this column exactly the same in all triggers for a logical database class. The BNF or Backus Naur Form of this parameter is defined below:

    <table-key> ::= <unique-row-identifier> {"+" 
                <unique-row-identifier>}

<unique-row-identifier> ::= <primary-key-column-name> "=" <value>

    For example, for the usr table referenced throughout this chapter, this column’s value might be idu=1.

    For the view_usr view referenced throughout this chapter, this column’s value might be pk_empno=1.

    For a hypothetical compound primary key (one containing multiple columns), this column’s value might be pkey1=value1+pkey2=value2.

    NOTE:If primary key values placed in the table_key field contains any of the special characters {, ; ' + " = \ < >}, where ’{’ and ’}’ contain the set of special characters, delimit the value with double quotes. You’ll also need to escape the double quote character " as \" and the literal escape character \ character as \\ when contained inside a pair of double quotes.

    For a hypothetical primary key containing special characters, this column’s value might be pkey=", ; ' + \" = \\ < >". (Note the double quotes and escaped characters.)

    NOTE:Differences in padding or formatting might result in out-of-order event processing. For performance reasons, remove any unnecessary white space from numeric values. For example, "idu=1" is preferred over "idu= 1". (Note the space in “idu= 1”.)

  8. column_name

    The name of the column that was changed. This column is used only for per-field (1-3, 7-8) event types. Nevertheless, it must always be present in the event log table. If it is missing, the Publisher channel cannot start.

  9. old_value

    The field’s old value. This column is used only for per-field, non-query-back event types (1-3). Nevertheless, it must always be present in the event log table. If it is missing, the Publisher channel cannot start.

  10. new_value

    The field’s new value. This column is used only by per-field, non-query-back event types (1-3). Nevertheless, it must always be present in the event log table. If it is missing, the Publisher channel cannot start.

5.3.2 Event Types

The following table describes each event type:

Table 5-11 Event Types

Event Type

Interpretation

1

insert field

2

update field

3

update field (remove all values)

4

delete row

5

insert row (query-back)

6

update row (query-back)

7

insert field (query-back)

8

update field (query-back)

Event types are in four major categories. Some categories overlap. The following table describes each category and indicates which event types are members:

Table 5-12 Event Categories and Types

Event Category

Event Types

Per-field (attribute)

1, 2, 3, 7, 8

Per-row (object)

4, 5, 6

Non-query-back

1, 2, 3, 4

Query-back

5, 6, 7, 8

Per-field, non-query-back

1, 2, 3

Per-field, query-back

7, 8

Per-row, non-query-back

4

Per-row, query-back

5, 6

In general, a combination of event types from each category yields the best trade-off in terms of space, time, implementation complexity, and peformance.

Per-field event types are more granular, require more space, and are more complex to implement than per-row event types. Per-row events are less granular, require less space, and are easier to implement than per-field event types.

Query-back event types use less space but require more time to process than non-query-back event types. Non-query-back event types use more space but require less time to process than query-back event types.

Query-back event types trump their non-query-back conterparts. Non-query-back events are ignored if a query-back event is logged for the same field or object. For example, if an event of type 2 (update-field, non-query-back) and 8 (update-field, query-back) are logged on the same field, the type 2 event is ignored in favor of the type 8 event.

Furthermore, query-back row event types trump query-back field event types. For example, if an event type 8 (update field, query-back) and a event type 6 (update row query-back) are logged on the same object, the type 8 event is ignored in favor of the type 6 event.

Query-back events are ignored by the Publisher if the database object no longer exists. They are dependent upon the database object still being around at processing time. Therefore, logged query-back adds and modifies (event types 5, 6, 7, 8) have no effect once the database object they refer to is deleted.

The following table shows the basic correlation between publication event types and the XDS XML generated by the Publisher channel.

Table 5-13 Basic Correlation of Publication Event Types

Event Type

Resulting XDS

insert

<add>

update

<modify>

delete

<delete>

The following example illustrates XML that the Publisher channel generates for events logged on the usr table for each possible event type.

CREATE TABLE indirect.usr
(
    idu   INTEGER  NOT NULL,
    fname VARCHAR2(64),
    photo LONGRAW,
    --...
    CONSTRAINT pk_usr_idu PRIMARY KEY(idu)
);

The following table shows the initial contents of usr after a new row has been inserted:

Table 5-14 An Inserted Row in the usr Table

idu

fname

lname

photo

1

Jack

Frost

0xAAAA

The following table shows the current contents of usr after the row has been updated:

Table 5-15 An Updated Row in the usr Table

idu

fname

lname

photo

1

John

Doe

0xBBBB

Insert Field

The table below shows the contents of the event log table after a new row is inserted into table usr. The value for column photo has been Base64-encoded. The Base64-encoded equivalent of 0xAAAA is qqo=.

Table 5-16 Event Log Table: Type 1

event_type

table

table_key

column_name

old_value

new_value

1

usr

idu=1

fname

NULL

Jack

1

usr

idu=1

lname

NULL

Frost

1

usr

idu=1

photo

NULL

qqo=

The Publisher channel generates the following XML:

<add class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <add-attr attr-name="fname">
        <value type="string">Jack</value>
    </add-attr>
    <add-attr attr-name="lname">
        <value type="string">Frost</value>
    </add-attr>
    <add-attr attr-name="photo">
        <value type="octet">qqo=</value>
    </add-attr>
</add>

Update Field

The following table shows the contents of the event log table after the row in table usr has been updated. The values for column photo has been Base64-encoded. The Base64-encoded equivalent of 0xBBBB is u7s=.

Table 5-17 Event Log Table: Type 2

event_type

table

table_key

column_name

old_value

new_value

2

usr

idu=1

fname

Jack

John

2

usr

idu=1

lname

Frost

Doe

2

usr

idu=1

photo

qqo=

u7s=

The Publisher channel generates the following XML:

<modify class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <modify-attr attr-name="fname">
        <remove-value>
            <value type="string">Jack</value>
        </remove-value>
        <add-value>
            <value type="string">John</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="lname">
        <remove-value>
            <value type="string">Frost</value>
        </remove-value>
        <add-value>
            <value type="string">Doe</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="photo">
        <remove-value>
            <value type="octet">qqo=</value>
        </remove-value>
        <add-value>
            <value type="octet">u7s=</value>
        </add-value>
    </modify-attr>
</modify>

Update Field (Remove-All-Values)

The following table shows the contents of the event log table after the row in table usr has been updated. The value for column photo has been Base64-encoded.

Table 5-18 Event Log Table: Type 3

event_type

table

table_key

column_name

old_value

new_value

3

usr

idu=1

fname

Jack

John

3

usr

idu=1

lname

Frost

Doe

3

usr

idu=1

photo

qqo=

u7s=

The Publisher channel generates the following XML:

<modify class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <modify-attr attr-name="fname">
        <remove-all-values/>
        <add-value>
            <value type="string">John</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="lname">
        <remove-all-values/>
        <add-value>
            <value type="string">Doe</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="photo">
        <remove-all-values/>
        <add-value>
            <value type="octet">u7s=</value>
        </add-value>
    </modify-attr>
</modify>

Delete Row

The table below shows the contents of the event log table after the row in table usr has been deleted.

Table 5-19 Event Log Table: Type 4

event_type

table

table_key

column_name

old_value

new_value

4

usr

idu=1

NULL

NULL

NULL

The Publisher channel generates the following XML:

<delete class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>	 
</delete>

Insert Row (Query-Back)

The following table shows the contents of the event log table after a new row is inserted into table usr.

Table 5-20 Event Log Table: Type 5

event_type

table

table_key

column_name

old_value

new_value

5

usr

idu=1

NULL

NULL

NULL

The Publisher channel generates the following XML. The values reflect the current contents of table usr, not the initial contents.

<add class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <add-attr attr-name="fname">
        <value type="string">John</value>
    </add-attr>
    <add-attr attr-name="lname">
        <value type="string">Doe</value>
    </add-attr>
    <add-attr attr-name="photo">
        <value type="octet">u7s=</value>
    </add-attr>
</add>

Update Row (Query-Back)

The table below shows the contents of the event log table after the row in table usr has been updated.

Table 5-21 Event Log Table: Type 6

event_type

table

table_key

column_name

old_value

new_value

6

usr

idu=1

NULL

NULL

NULL

The Publisher channel generates the following XML. The values reflect the current contents of table usr, not the initial contents.

<modify class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <modify-attr attr-name="fname">
        <remove-all-values/>
        <add-value>
            <value type="string">John</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="lname">
        <remove-all-values/>
        <add-value>
            <value type="string">Doe</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="photo">
        <remove-all-values/>
        <add-value>
            <value type="octet">u7s=</value>
        </add-value>
    </modify-attr>
</modify>

Insert Field (Query-Back)

The following table shows the contents of the event log table after a new row is inserted into table usr. Old and new values are omitted because they are not used.

Table 5-22 Event Log Table: Type 7

event_type

table

table_key

column_name

old_value

new_value

7

usr

idu=1

fname

NULL

NULL

7

usr

idu=1

lname

NULL

NULL

7

usr

idu=1

photo

NULL

NULL

The Publisher channel generates the following XML. The values reflect the current contents of table usr, not the initial contents.

<add class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <add-attr attr-name="fname">
        <value type="string">John</value>
    </add-attr>
    <add-attr attr-name="lname">
        <value type="string">Doe</value>
    </add-attr>
    <add-attr attr-name="photo">
        <value type="octet">u7s=</value>
    </add-attr>
</add>

Update Field (Query-Back)

The following table shows the contents of the event log table after the row in table usr has been updated. Old and new values are omitted because they are not used.

Table 5-23 Event Log Table: Type 8

event_type

table

table_key

column_name

old_value

new_value

8

usr

idu=1

fname

NULL

NULL

8

usr

idu=1

lname

NULL

NULL

8

usr

idu=1

photo

NULL

NULL

The Publisher channel generates the following XML. The values reflect the current contents of table usr, not the initial contents.

<modify class-name="usr">
    <association>idu=1,table=usr,schema=indirect
    </association>
    <modify-attr attr-name="fname">
        <remove-all-values/>
        <add-value>
            <value type="string">John</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="lname">
        <remove-all-values/>
        <add-value>
            <value type="string">Doe</value>
        </add-value>
    </modify-attr>
    <modify-attr attr-name="photo">
        <remove-all-values/>
        <add-value>
            <value type="octet">u7s=</value>
        </add-value>
    </modify-attr>
</modify>