Priority groups
allow you to determine the validity of data based on its value. The priority group conflict resolution technique is most effective for data that has a finite range of possible values, and that goes through this range in a specific order.

The PRODUCTION_STATUS field in this table can only take on certain values: CONCEPT, DEVELOPMENT, BETA, PRODUCTION, and DISCONTINUED. In addition, products must go through this range of values in the order given.

This concept of a sequential range of values is known as a
workflow
, and priority groups are designed to enforce the rules of a workflow in a replicated environment. Unlike column groups, which pertain to fields in a specific table, you can define a priority group for a specific column, which may appear in one or more tables. Once you define and configure a priority group, you can designate it to resolve update conflicts within a column group. The basic idea is that if a conflict arises, the row with the data corresponding to the higher priority in the workflow
"wins."

DBMS_REPCAT's DEFINE_PRIORITY_GROUP and DROP_PRIORITY_GROUP procedures allow you to create and drop priority groups. You use the COMMENT_ON_PRIORITY_GROUP procedure to maintain the comment on the priority group.

Since priority groups are meant to work with a specific range of values, you must specify the datatype of these values when you create the group. Valid datatypes follow:

CHAR

NCHAR (Oracle8 only)

VARCHAR2

NUMBER

DATE

RAW

If the data type is CHAR, then you must also specify the length of the data with the fixed_length parameter.
After you create a priority group, you must run DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT for any object in the same replication group to propagate the new priority group to other master sites. (Since priority groups are not associated with a specific object, it does not matter what object you use in the call the GENERATE_REPLICATION_SUPPORT.)

WARNING:
Do not drop a priority group that you have designated as an
UPDATE conflict resolution method for a column group. You must first use DROP_UPDATE_RESOLUTION for the column group. Records in the data dictionary view DBA_REPRESOLUTION indicate if and where the priority group is used. Attempting to drop a priority group that is in use raises the
referenced
exception.

The
COMMENT_ON_PRIORITY_GROUP procedure allows you to create or replace the comment for a priority group (as seen in the DBA_REPPRIORITY_GROUP data dictionary view). The specifications for Oracle7 and Oracle8 differ as follows.

The next step after creating a priority group is to add priorities to it. This task entails specifying every possible value for the data in the priority group, and assigning a priority to each value.

For example, recall the PRODUCTION_STATUS field we described earlier, which has this range of five possible values:

CONCEPT

DEVELOPMENT

BETA

PRODUCTION

DISCONTINUED

We want to resolve conflicts for this data by accepting the data that is furthest in the production cycle. If a conflict arises in which one update has PRODUCTION_STATUS set to "BETA," and another update has it set to "PRODUCTION," we would take the data from the latter
update.

The examples in the following sections illustrate exactly how to implement this priority group. We will show the following packages:

DBMS_REPCAT.ADD_PRIORITY_<datatype>

DBMS_REPCAT.ALTER_PRIORITY

DBMS_REPCAT.ALTER_PRIORITY_<datatype>

DBMS_REPCAT.DROP_PRIORITY

DBMS_REPCAT.DROP_PRIORITY_<datatype>

NOTE:
Each of the procedures containing the <datatype> suffix actually has five different versions in Oracle7, one for each of the datatypes CHAR, VARCHAR2, NUMBER, RAW, and DATE. Oracle8 adds support for two more datatypes: NCHAR and NVARCHAR2. The usage of each of these packages is identical. Most of the examples in the following sections will use the VARCHAR2 version of these packages.

To associate priorities with each of the five possible values of PRODUCTION_STATUS, we must make five calls to ADD_PRIORITY_VARCHAR2. After making these calls and a call to DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT, the column group is completely configured.

Suppose that our requirements change such that we want the PRODUCTION_STATUS value DEVELOPMENT to have higher priority than BETA. We can accomplish this by changing the priority associated with DEVELOPMENT from 30 to 45.

The DROP_PRIORITY and DROP_PRIORITY_<datatype> remove values from a priority group. You can specify the value to be removed by priority (with DROP_PRIORITY) or by data value (with DROP_PRIORITY_<datatype>).

The
DROP_PRIORITY procedure removes a value from a priority group. In this version of the procedure, you must specify the value by priority. The specifications differ for Oracle7 and Oracle 8 as follows.

The
DROP_PRIORITY_<datatype> procedure removes a value from a priority group. In this version of the procedure, you can specify the value by data value. The specifications differ for Oracle7 and Oracle 8 as follows.

You can specify the member to be dropped by its data value rather than its priority (as was done with DROP_PRIORITY). In the following example, we drop the member of the PG_PRODUCTION_STATUS priority group whose value is CONCEPT: