|View source on GitHub|
Adds an attached message to the module definition.
hub.attach_message( key, message )
DEPRECATION NOTE: This belongs to the hub.Module API and TF1 Hub format. For TF2, switch to plain SavedModels.
See ModuleSpec.get_attached_message() for an introduction to attached messages and the API for module consumers.
To define a new type of attached message:
Select a reasonably descriptive name as a unique key. For now, keys must be valid Python identifiers that start with a letter. Punctuation besides underscores ('_') is reserved for future use in hierarchical names.
Define a Protocol Buffer message type to store the value for the key. (Use generic containers like google.protobuf.Value only if running the protocol compiler is infeasible for your build process.)
For module consumers, consider providing a small library that encapsulates the specific call to get_attached_message() behind a higher-level interface and supplies the right message type for parsing.
Attached messages work best for few messages of moderate size. Avoid a large number of messages; use repetition within messages instead. Avoid large messages (megabytes); consider module assets instead.
For modules with multiple graph versions, each graph version stores separately
what was attached from within the call to
module_fn that defines its graph.
A string with the unique key to retrieve this message. Must start
with a letter and contain only letters, digits and underscores. If used
repeatedly within one invocation of
||A protocol message object, to be stored in serialized form.|