diff options
author | Paul Yang <TeBoring@users.noreply.github.com> | 2017-10-05 21:03:57 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2017-10-05 21:03:57 -0700 |
commit | 77f64bb7779ec2195f9bc4dc82497d12c18fc6b7 (patch) | |
tree | 0c1b7683a15ecd6fb597a05aaaae08cf4420107e /php/src/Google/Protobuf/FieldMask.php | |
parent | cd5f49d0942e19a5854a325941918fca02fdb409 (diff) | |
download | protobuf-77f64bb7779ec2195f9bc4dc82497d12c18fc6b7.tar.gz protobuf-77f64bb7779ec2195f9bc4dc82497d12c18fc6b7.tar.bz2 protobuf-77f64bb7779ec2195f9bc4dc82497d12c18fc6b7.zip |
Add well known types to php runtime. (#3697)
* Add well known types to php runtime.
* Fix php7.0 tests
* No longer generate empty.proto in test as it has been included in
runtime.
* Fix zts build
* Clean code
* Rename g_p_b_empty to empty.
* Don't generate code for empty.proto in compatibility test
* Fix 32-bit
* Fix mac build
* Fix Makefile.am to add new files
Diffstat (limited to 'php/src/Google/Protobuf/FieldMask.php')
-rw-r--r-- | php/src/Google/Protobuf/FieldMask.php | 209 |
1 files changed, 209 insertions, 0 deletions
diff --git a/php/src/Google/Protobuf/FieldMask.php b/php/src/Google/Protobuf/FieldMask.php new file mode 100644 index 00000000..e18586af --- /dev/null +++ b/php/src/Google/Protobuf/FieldMask.php @@ -0,0 +1,209 @@ +<?php +# Generated by the protocol buffer compiler. DO NOT EDIT! +# source: google/protobuf/field_mask.proto + +namespace Google\Protobuf; + +use Google\Protobuf\Internal\GPBType; +use Google\Protobuf\Internal\RepeatedField; +use Google\Protobuf\Internal\GPBUtil; + +/** + * `FieldMask` represents a set of symbolic field paths, for example: + * paths: "f.a" + * paths: "f.b.d" + * Here `f` represents a field in some root message, `a` and `b` + * fields in the message found in `f`, and `d` a field found in the + * message in `f.b`. + * Field masks are used to specify a subset of fields that should be + * returned by a get operation or modified by an update operation. + * Field masks also have a custom JSON encoding (see below). + * # Field Masks in Projections + * When used in the context of a projection, a response message or + * sub-message is filtered by the API to only contain those fields as + * specified in the mask. For example, if the mask in the previous + * example is applied to a response message as follows: + * f { + * a : 22 + * b { + * d : 1 + * x : 2 + * } + * y : 13 + * } + * z: 8 + * The result will not contain specific values for fields x,y and z + * (their value will be set to the default, and omitted in proto text + * output): + * f { + * a : 22 + * b { + * d : 1 + * } + * } + * A repeated field is not allowed except at the last position of a + * paths string. + * If a FieldMask object is not present in a get operation, the + * operation applies to all fields (as if a FieldMask of all fields + * had been specified). + * Note that a field mask does not necessarily apply to the + * top-level response message. In case of a REST get operation, the + * field mask applies directly to the response, but in case of a REST + * list operation, the mask instead applies to each individual message + * in the returned resource list. In case of a REST custom method, + * other definitions may be used. Where the mask applies will be + * clearly documented together with its declaration in the API. In + * any case, the effect on the returned resource/resources is required + * behavior for APIs. + * # Field Masks in Update Operations + * A field mask in update operations specifies which fields of the + * targeted resource are going to be updated. The API is required + * to only change the values of the fields as specified in the mask + * and leave the others untouched. If a resource is passed in to + * describe the updated values, the API ignores the values of all + * fields not covered by the mask. + * If a repeated field is specified for an update operation, the existing + * repeated values in the target resource will be overwritten by the new values. + * Note that a repeated field is only allowed in the last position of a `paths` + * string. + * If a sub-message is specified in the last position of the field mask for an + * update operation, then the existing sub-message in the target resource is + * overwritten. Given the target message: + * f { + * b { + * d : 1 + * x : 2 + * } + * c : 1 + * } + * And an update message: + * f { + * b { + * d : 10 + * } + * } + * then if the field mask is: + * paths: "f.b" + * then the result will be: + * f { + * b { + * d : 10 + * } + * c : 1 + * } + * However, if the update mask was: + * paths: "f.b.d" + * then the result would be: + * f { + * b { + * d : 10 + * x : 2 + * } + * c : 1 + * } + * In order to reset a field's value to the default, the field must + * be in the mask and set to the default value in the provided resource. + * Hence, in order to reset all fields of a resource, provide a default + * instance of the resource and set all fields in the mask, or do + * not provide a mask as described below. + * If a field mask is not present on update, the operation applies to + * all fields (as if a field mask of all fields has been specified). + * Note that in the presence of schema evolution, this may mean that + * fields the client does not know and has therefore not filled into + * the request will be reset to their default. If this is unwanted + * behavior, a specific service may require a client to always specify + * a field mask, producing an error if not. + * As with get operations, the location of the resource which + * describes the updated values in the request message depends on the + * operation kind. In any case, the effect of the field mask is + * required to be honored by the API. + * ## Considerations for HTTP REST + * The HTTP kind of an update operation which uses a field mask must + * be set to PATCH instead of PUT in order to satisfy HTTP semantics + * (PUT must only be used for full updates). + * # JSON Encoding of Field Masks + * In JSON, a field mask is encoded as a single string where paths are + * separated by a comma. Fields name in each path are converted + * to/from lower-camel naming conventions. + * As an example, consider the following message declarations: + * message Profile { + * User user = 1; + * Photo photo = 2; + * } + * message User { + * string display_name = 1; + * string address = 2; + * } + * In proto a field mask for `Profile` may look as such: + * mask { + * paths: "user.display_name" + * paths: "photo" + * } + * In JSON, the same mask is represented as below: + * { + * mask: "user.displayName,photo" + * } + * # Field Masks and Oneof Fields + * Field masks treat fields in oneofs just as regular fields. Consider the + * following message: + * message SampleMessage { + * oneof test_oneof { + * string name = 4; + * SubMessage sub_message = 9; + * } + * } + * The field mask can be: + * mask { + * paths: "name" + * } + * Or: + * mask { + * paths: "sub_message" + * } + * Note that oneof type names ("test_oneof" in this case) cannot be used in + * paths. + * + * Generated from protobuf message <code>google.protobuf.FieldMask</code> + */ +class FieldMask extends \Google\Protobuf\Internal\Message +{ + /** + * The set of field mask paths. + * + * Generated from protobuf field <code>repeated string paths = 1;</code> + */ + private $paths; + + public function __construct() { + \GPBMetadata\Google\Protobuf\FieldMask::initOnce(); + parent::__construct(); + } + + /** + * The set of field mask paths. + * + * Generated from protobuf field <code>repeated string paths = 1;</code> + * @return \Google\Protobuf\Internal\RepeatedField + */ + public function getPaths() + { + return $this->paths; + } + + /** + * The set of field mask paths. + * + * Generated from protobuf field <code>repeated string paths = 1;</code> + * @param string[]|\Google\Protobuf\Internal\RepeatedField $var + * @return $this + */ + public function setPaths($var) + { + $arr = GPBUtil::checkRepeatedField($var, \Google\Protobuf\Internal\GPBType::STRING); + $this->paths = $arr; + + return $this; + } + +} + |