Property Names allow a replica to be labeled. Replicas that are labeled may be grouped, which becomes important when using the START AFTER COMMIT feature (see START AFTER COMMIT ...). For example, you might have some replicas that are related to the bicycle industry and others that are related to the surfboard industry, and you may want to update each of those groups of replicas separately. You can use Property Names to group these replicas. All members of a group have the same property and have the same value for that property.
Properties and values may be almost any arbitrary names and literals. For example:
Property
Some Possible Values
Region
north, south, east, west
Color
red, yellow, green, blue, rainbow, transparent
Mood
upbeat, blue
Philosophy
realist, nihilist, purple
Because the properties and values have no meaning to the server and are simply arbitrary labels, the values do not need to "make sense". If you decide that "purple" is a useful value in the "philosophy" category, then go ahead and use it. Furthermore, different properties may use overlapping values. If you decide that "blue" is both a useful color and a useful mood, then you may use it as a value for both properties. (A server categorized as having a blue mood will NOT fall into the same category as servers having a blue color; properties are completely independent.)
A server may have more than one property, and thus may belong to more than one group. For example, my replica might have
Region = west
Color = green
A server does not have to have a setting for every possible property; my replica might not have any Philosophy or Mood property at all.
For examples of using properties, see the section on the START AFTER COMMIT command.
Replica property names may be added at any time, and new replicas may also be added at any time. By using property names to group your replicas, you avoid having to rewrite the logic on the master to call remote stored procedures on replicas. For example, suppose that you want to notify all offices in the "north" region when a particular piece of data is updated. If you add a new office (replica), you can simply give that new office the property "Region=north", and that new office will automatically be notified when relevant data is updated. Nothing on the master needs to be changed, except that the master must be notified that the new replica has the property "Region=north". Also, the new replica must have a copy of the stored procedure that the master expects to call.
Every replica has an implicit property called "name", which is the node name assigned to the replica when it was registered.
A replica's properties are useful in Sync Pull Notify only if the master knows the replica's properties. Either the master or the replica may set a property for the replica. If the replica sets its own property, then it must notify the master of that property and value. The replica can send its properties to the master with the messages using SAVE. The master can set properties for a named replica with the SET command.
Syntax in master:
SET SYNC PROPERTY <propertyname> = { ’value’ | NONE } FOR REPLICA <replicaname>
Syntax in replica:
SAVE SET SYNC PROPERTY <propertyname> = { ’value’ | NONE; }
Examples
Master:
SET SYNC PROPERTY color = ’red’ FOR REPLICA replica_node_01; SET SYNC PROPERTY color = NONE FOR REPLICA replica_node_01;
Replica:
SAVE SET SYNC PROPERTY color = ’red’; SAVE SET SYNC PROPERTY color = NONE;