PruningRules

A set of rules that describes which types and members to retain and which to remove.

Members may be pruned using either their identifier (package, type name, member name) or their version (since and until options).

Despite the builder, instances of this class are not safe for concurrent use.

Identifier Matching

If a member is a root in the set, its type is implicitly also considered a root. A type that is a root without a specific member implicitly set all of that type's members as roots, but not its nested types.

Identifiers in this set may be in the following forms:

• Package names, followed by .*, like squareup.protos.person.*. This matches types and services defined in the package and its descendant packages.

• Fully qualified type and service names, like squareup.protos.person.Person.

• Fully qualified member names, which are type names followed by a '#', followed by a member name, like squareup.protos.person.Person#address. Members may be fields, enum constants or RPCs.

An identifier set populated with Movie and Actor#name contains all members of Movie (such as Movie#name and Movie#release_date). It contains the type Actor and one member Actor#name, but not Actor#birth_date or Actor#oscar_count.

This set has root identifiers and prune identifiers, with the most precise identifier taking precedence over the other ones. For instance, if there is one root identifier a.Movie along a pruning identifier a.*, the type a.Movie is considered a root.

If the roots set is empty, that implies that all elements are considered roots. Use this to prune unwanted types and members without also marking everything else as roots.

Version Matching

Members may be declared with wire.since and wire.until options. For example, these options declare a field age that was replaced with birth_date in version "5.0":

optional int32 age = 3 [(wire.until) = "5.0"];
optional Date birth_date = 4 [(wire.since) = "5.0"];

Client code should typically target a single version. In this example, versions <= "4.0" will have the age field only and versions >= "5.0" will have the birth_date field only. One can target a single version using only.

Service code that supports many clients should support the union of versions of all supported clients. Such code will have both the age and birth_date fields.