Class: Google::Apis::CloudsearchV1::PreState

Inherits:
Object
  • Object
show all
Includes:
Google::Apis::Core::Hashable, Google::Apis::Core::JsonObjectSupport
Defined in:
lib/google/apis/cloudsearch_v1/classes.rb,
lib/google/apis/cloudsearch_v1/representations.rb,
lib/google/apis/cloudsearch_v1/representations.rb

Overview

State of the thread previous to the update. This really just describes the label state of all messages before the update.

Instance Attribute Summary collapse

Instance Method Summary collapse

Constructor Details

#initialize(**args) ⇒ PreState

Returns a new instance of PreState.



15628
15629
15630
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15628

def initialize(**args)
   update!(**args)
end

Instance Attribute Details

#label_ids ⇒ Array<String>

Corresponds to the JSON property labelIds

Returns:

  • (Array<String>) 


15559
15560
15561
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15559

def label_ids
  @label_ids
end

#message_key ⇒ Google::Apis::CloudsearchV1::MultiKey

A union-like type for identifiying an object in storage. MultiKeys contain multiple key fields, each in a separate key space. At least one key field must be set. More than one key field may be set as long as all key values refer to the same object. All objects in storage have unique server_id keys. All MultiKeys returned from storage to storage clients will always have the server_id field set. When creating an object, if a MultiKey without a server_id is supplied to storage, the storage system will auto-assign a server ID to the new object. For all other storage requests (i.e. those not creating new objects), clients may omit server_id (as long as they supply another key). Instead of server ids, clients can specify string based client_assigned_perm_id keys. Mail message drafts are a prime example of these kinds of objects. Each time a user saves a new version of a draft, the storage system needs to create a new object with the updated draft content and needs to delete the object containing the old content. The new object gets a new SERVER_ID but should get the same CLIENT_ASSIGNED_PERM_ID as the now-deleted object containing the old content. Carrying forward the perm ID allows it to be used to consistently refer to the same logical object across revisions. These perm IDs save sync clients from having to deal with changing object IDs. For example, assume there's a mail message in storage with SERVER_ID = 123 and CLIENT_ASSIGNED_PERM_ID = "foo". The following are all valid ways of addressing the object using MultiKeys: 1) MultiKey server_id = 123 2) MultiKey server_id = 123, client_assigned_perm_id = "foo" 3) MultiKey client_assigned_perm_id = "foo" Multikeys are never serialized in the storage. The individual keys are extracted and processed separately. Both the integer ids as well as string ids are indexed for efficient retrieval using the same fields in the backend. See go/tingle-multikeys for more information on background and motivation. Corresponds to the JSON property messageKey

Returns:



15590
15591
15592
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15590

def message_key
  @message_key
end

#sync_ids ⇒ Array<Fixnum>

Note that there can be fewer sync ids than label ids. Corresponds to the JSON property syncIds

Returns:

  • (Array<Fixnum>) 


15595
15596
15597
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15595

def sync_ids
  @sync_ids
end

#thread_key ⇒ Google::Apis::CloudsearchV1::MultiKey

A union-like type for identifiying an object in storage. MultiKeys contain multiple key fields, each in a separate key space. At least one key field must be set. More than one key field may be set as long as all key values refer to the same object. All objects in storage have unique server_id keys. All MultiKeys returned from storage to storage clients will always have the server_id field set. When creating an object, if a MultiKey without a server_id is supplied to storage, the storage system will auto-assign a server ID to the new object. For all other storage requests (i.e. those not creating new objects), clients may omit server_id (as long as they supply another key). Instead of server ids, clients can specify string based client_assigned_perm_id keys. Mail message drafts are a prime example of these kinds of objects. Each time a user saves a new version of a draft, the storage system needs to create a new object with the updated draft content and needs to delete the object containing the old content. The new object gets a new SERVER_ID but should get the same CLIENT_ASSIGNED_PERM_ID as the now-deleted object containing the old content. Carrying forward the perm ID allows it to be used to consistently refer to the same logical object across revisions. These perm IDs save sync clients from having to deal with changing object IDs. For example, assume there's a mail message in storage with SERVER_ID = 123 and CLIENT_ASSIGNED_PERM_ID = "foo". The following are all valid ways of addressing the object using MultiKeys: 1) MultiKey server_id = 123 2) MultiKey server_id = 123, client_assigned_perm_id = "foo" 3) MultiKey client_assigned_perm_id = "foo" Multikeys are never serialized in the storage. The individual keys are extracted and processed separately. Both the integer ids as well as string ids are indexed for efficient retrieval using the same fields in the backend. See go/tingle-multikeys for more information on background and motivation. Corresponds to the JSON property threadKey

Returns:



15626
15627
15628
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15626

def thread_key
  @thread_key
end

Instance Method Details

#update!(**args) ⇒ Object

Update properties of this object



15633
15634
15635
15636
15637
15638
 
# File 'lib/google/apis/cloudsearch_v1/classes.rb', line 15633

def update!(**args)
  @label_ids = args[:label_ids] if args.key?(:label_ids)
  @message_key = args[:message_key] if args.key?(:message_key)
  @sync_ids = args[:sync_ids] if args.key?(:sync_ids)
  @thread_key = args[:thread_key] if args.key?(:thread_key)
end