iOS/Pods/Protobuf/objectivec/google/protobuf/FieldMask.pbobjc.h

   1 // Generated by the protocol buffer compiler.  DO NOT EDIT!
   2 // source: google/protobuf/field_mask.proto
   3
   4 // This CPP symbol can be defined to use imports that match up to the framework
   5 // imports needed when using CocoaPods.
   6 #if !defined(GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS)
   7  #define GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS 0
   8 #endif
   9
  10 #if GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS
  11  #import <Protobuf/GPBDescriptor.h>
  12  #import <Protobuf/GPBMessage.h>
  13  #import <Protobuf/GPBRootObject.h>
  14 #else
  15  #import "GPBDescriptor.h"
  16  #import "GPBMessage.h"
  17  #import "GPBRootObject.h"
  18 #endif
  19
  20 #if GOOGLE_PROTOBUF_OBJC_VERSION < 30002
  21 #error This file was generated by a newer version of protoc which is incompatible with your Protocol Buffer library sources.
  22 #endif
  23 #if 30002 < GOOGLE_PROTOBUF_OBJC_MIN_SUPPORTED_VERSION
  24 #error This file was generated by an older version of protoc which is incompatible with your Protocol Buffer library sources.
  25 #endif
  26
  27 // @@protoc_insertion_point(imports)
  28
  29 #pragma clang diagnostic push
  30 #pragma clang diagnostic ignored "-Wdeprecated-declarations"
  31
  32 CF_EXTERN_C_BEGIN
  33
  34 NS_ASSUME_NONNULL_BEGIN
  35
  36 #pragma mark - GPBFieldMaskRoot
  37
  38 /**
  39  * Exposes the extension registry for this file.
  40  *
  41  * The base class provides:
  42  * @code
  43  *   + (GPBExtensionRegistry *)extensionRegistry;
  44  * @endcode
  45  * which is a @c GPBExtensionRegistry that includes all the extensions defined by
  46  * this file and all files that it depends on.
  47  **/
  48 @interface GPBFieldMaskRoot : GPBRootObject
  49 @end
  50
  51 #pragma mark - GPBFieldMask
  52
  53 typedef GPB_ENUM(GPBFieldMask_FieldNumber) {
  54   GPBFieldMask_FieldNumber_PathsArray = 1,
  55 };
  56
  57 /**
  58  * `FieldMask` represents a set of symbolic field paths, for example:
  59  *
  60  *     paths: "f.a"
  61  *     paths: "f.b.d"
  62  *
  63  * Here `f` represents a field in some root message, `a` and `b`
  64  * fields in the message found in `f`, and `d` a field found in the
  65  * message in `f.b`.
  66  *
  67  * Field masks are used to specify a subset of fields that should be
  68  * returned by a get operation or modified by an update operation.
  69  * Field masks also have a custom JSON encoding (see below).
  70  *
  71  * # Field Masks in Projections
  72  *
  73  * When used in the context of a projection, a response message or
  74  * sub-message is filtered by the API to only contain those fields as
  75  * specified in the mask. For example, if the mask in the previous
  76  * example is applied to a response message as follows:
  77  *
  78  *     f {
  79  *       a : 22
  80  *       b {
  81  *         d : 1
  82  *         x : 2
  83  *       }
  84  *       y : 13
  85  *     }
  86  *     z: 8
  87  *
  88  * The result will not contain specific values for fields x,y and z
  89  * (their value will be set to the default, and omitted in proto text
  90  * output):
  91  *
  92  *
  93  *     f {
  94  *       a : 22
  95  *       b {
  96  *         d : 1
  97  *       }
  98  *     }
  99  *
 100  * A repeated field is not allowed except at the last position of a
 101  * paths string.
 102  *
 103  * If a FieldMask object is not present in a get operation, the
 104  * operation applies to all fields (as if a FieldMask of all fields
 105  * had been specified).
 106  *
 107  * Note that a field mask does not necessarily apply to the
 108  * top-level response message. In case of a REST get operation, the
 109  * field mask applies directly to the response, but in case of a REST
 110  * list operation, the mask instead applies to each individual message
 111  * in the returned resource list. In case of a REST custom method,
 112  * other definitions may be used. Where the mask applies will be
 113  * clearly documented together with its declaration in the API.  In
 114  * any case, the effect on the returned resource/resources is required
 115  * behavior for APIs.
 116  *
 117  * # Field Masks in Update Operations
 118  *
 119  * A field mask in update operations specifies which fields of the
 120  * targeted resource are going to be updated. The API is required
 121  * to only change the values of the fields as specified in the mask
 122  * and leave the others untouched. If a resource is passed in to
 123  * describe the updated values, the API ignores the values of all
 124  * fields not covered by the mask.
 125  *
 126  * If a repeated field is specified for an update operation, the existing
 127  * repeated values in the target resource will be overwritten by the new values.
 128  * Note that a repeated field is only allowed in the last position of a `paths`
 129  * string.
 130  *
 131  * If a sub-message is specified in the last position of the field mask for an
 132  * update operation, then the existing sub-message in the target resource is
 133  * overwritten. Given the target message:
 134  *
 135  *     f {
 136  *       b {
 137  *         d : 1
 138  *         x : 2
 139  *       }
 140  *       c : 1
 141  *     }
 142  *
 143  * And an update message:
 144  *
 145  *     f {
 146  *       b {
 147  *         d : 10
 148  *       }
 149  *     }
 150  *
 151  * then if the field mask is:
 152  *
 153  *  paths: "f.b"
 154  *
 155  * then the result will be:
 156  *
 157  *     f {
 158  *       b {
 159  *         d : 10
 160  *       }
 161  *       c : 1
 162  *     }
 163  *
 164  * However, if the update mask was:
 165  *
 166  *  paths: "f.b.d"
 167  *
 168  * then the result would be:
 169  *
 170  *     f {
 171  *       b {
 172  *         d : 10
 173  *         x : 2
 174  *       }
 175  *       c : 1
 176  *     }
 177  *
 178  * In order to reset a field's value to the default, the field must
 179  * be in the mask and set to the default value in the provided resource.
 180  * Hence, in order to reset all fields of a resource, provide a default
 181  * instance of the resource and set all fields in the mask, or do
 182  * not provide a mask as described below.
 183  *
 184  * If a field mask is not present on update, the operation applies to
 185  * all fields (as if a field mask of all fields has been specified).
 186  * Note that in the presence of schema evolution, this may mean that
 187  * fields the client does not know and has therefore not filled into
 188  * the request will be reset to their default. If this is unwanted
 189  * behavior, a specific service may require a client to always specify
 190  * a field mask, producing an error if not.
 191  *
 192  * As with get operations, the location of the resource which
 193  * describes the updated values in the request message depends on the
 194  * operation kind. In any case, the effect of the field mask is
 195  * required to be honored by the API.
 196  *
 197  * ## Considerations for HTTP REST
 198  *
 199  * The HTTP kind of an update operation which uses a field mask must
 200  * be set to PATCH instead of PUT in order to satisfy HTTP semantics
 201  * (PUT must only be used for full updates).
 202  *
 203  * # JSON Encoding of Field Masks
 204  *
 205  * In JSON, a field mask is encoded as a single string where paths are
 206  * separated by a comma. Fields name in each path are converted
 207  * to/from lower-camel naming conventions.
 208  *
 209  * As an example, consider the following message declarations:
 210  *
 211  *     message Profile {
 212  *       User user = 1;
 213  *       Photo photo = 2;
 214  *     }
 215  *     message User {
 216  *       string display_name = 1;
 217  *       string address = 2;
 218  *     }
 219  *
 220  * In proto a field mask for `Profile` may look as such:
 221  *
 222  *     mask {
 223  *       paths: "user.display_name"
 224  *       paths: "photo"
 225  *     }
 226  *
 227  * In JSON, the same mask is represented as below:
 228  *
 229  *     {
 230  *       mask: "user.displayName,photo"
 231  *     }
 232  *
 233  * # Field Masks and Oneof Fields
 234  *
 235  * Field masks treat fields in oneofs just as regular fields. Consider the
 236  * following message:
 237  *
 238  *     message SampleMessage {
 239  *       oneof test_oneof {
 240  *         string name = 4;
 241  *         SubMessage sub_message = 9;
 242  *       }
 243  *     }
 244  *
 245  * The field mask can be:
 246  *
 247  *     mask {
 248  *       paths: "name"
 249  *     }
 250  *
 251  * Or:
 252  *
 253  *     mask {
 254  *       paths: "sub_message"
 255  *     }
 256  *
 257  * Note that oneof type names ("test_oneof" in this case) cannot be used in
 258  * paths.
 259  *
 260  * ## Field Mask Verification
 261  *
 262  * The implementation of any API method which has a FieldMask type field in the
 263  * request should verify the included field paths, and return an
 264  * `INVALID_ARGUMENT` error if any path is duplicated or unmappable.
 265  **/
 266 @interface GPBFieldMask : GPBMessage
 267
 268 /** The set of field mask paths. */
 269 @property(nonatomic, readwrite, strong, null_resettable) NSMutableArray<NSString*> *pathsArray;
 270 /** The number of items in @c pathsArray without causing the array to be created. */
 271 @property(nonatomic, readonly) NSUInteger pathsArray_Count;
 272
 273 @end
 274
 275 NS_ASSUME_NONNULL_END
 276
 277 CF_EXTERN_C_END
 278
 279 #pragma clang diagnostic pop
 280
 281 // @@protoc_insertion_point(global_scope)