event_type#

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

Per-field events#

Per-field event types are more granular, require more space in the processing tables, and are more complex to implement than per-row event types.

Per-row events#

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

Query-back events#

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

Non-query-back events#

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 queryback adds and modifies (event types 5, 6, 7, 8) have no effect once the database object they refer to is deleted.

General Rules#

If there is one filed being modified then the non-query-back event_type is probably the better choice. However if three or more attributes are modified, the query-back event types are probably better.

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:

Event Type	Interpretation	Event Category	Description
1	insert field	Per-field (attribute)	One event is needed for each field/attribute/column that changes. A specific field/attribute/column value did not exist and is then set for the first time.
2	update field	Per-field (attribute)	One event is needed for each field/attribute/column that changes. A specific field/attribute/column changes from one value to another.
3	update field (remove all values)	Per-field (attribute)	Removes all values and replace the values with the "New" Value
4	delete row	Per-row (object)	Indicate that the connector should delete the entry in eDirectory.
5	insert row (query-back)	Per-row (object)	Only one event needs to be created for all data to be updated in the IDV. Used to indicate that the connector should add the entry in eDirectory.
6	update row (query-back)	Per-row (object)	Only one event needs to be created for all data to be updated in the IDV. Removes all values on the entry in eDirectory and adds the most current one from the application back to the IDV.
7	insert field (query-back)	Per-field (attribute)
8	update field (query-back)	Per-field (attribute)

More Information#

There might be more information for this subject on one of the following:

• Publisher Event Log