Jump to: navigation, search

Difference between revisions of "Zaqar/bp/metadata-endpoint"

Line 5: Line 5:
 
The goal of adding a metadata endpoint is twofold.
 
The goal of adding a metadata endpoint is twofold.
  
1. Decouple metadata updates from queue creation.
+
# Decouple metadata updates from queue creation.
2. Decouple metadata (user-defined values) from configuration (server-defined values)
+
# Decouple metadata (user-defined values) from configuration (server-defined values)
  
 
=== Decoupling Creation ===
 
=== Decoupling Creation ===
Line 16: Line 16:
 
This is the more prominent of the two reasons. Currently, we want to define certain queue configuration parameters that affect all data stored in the queue. Example gives include:
 
This is the more prominent of the two reasons. Currently, we want to define certain queue configuration parameters that affect all data stored in the queue. Example gives include:
  
* TTL: defines the default time-to-live for messages posted to this queue
+
# TTL: defines the default time-to-live for messages posted to this queue
* Max message size: different than the server default
+
# Max message size: different than the server default
  
 
We don't want these to collide with user-defined metadata, but we want users to be able to modify these values.
 
We don't want these to collide with user-defined metadata, but we want users to be able to modify these values.
Line 27: Line 27:
 
Two changes are required here:
 
Two changes are required here:
  
1. Ignore anything placed in the message body. PUT does not update metadata.
+
* Ignore anything placed in the message body. PUT does not update metadata.
2. At the storage layer, have the queue controller's upsert operation leave metadata alone.
+
* At the storage layer, have the queue controller's upsert operation leave metadata alone.
  
 
=== PUT /v1/queues/{name}/metadata ===
 
=== PUT /v1/queues/{name}/metadata ===

Revision as of 15:28, 23 July 2013

This page was created to capture the design considerations for a new metadata endpoint. First things first:

Rationale

The goal of adding a metadata endpoint is twofold.

  1. Decouple metadata updates from queue creation.
  2. Decouple metadata (user-defined values) from configuration (server-defined values)

Decoupling Creation

While convenient, having queue creation tied to metadata updates forces (for certain storage engines) the metadata to be stored with the queue. This is currently optimal, but it limits us from changing this in the future.

Decoupling Metadata from Configuration

This is the more prominent of the two reasons. Currently, we want to define certain queue configuration parameters that affect all data stored in the queue. Example gives include:

  1. TTL: defines the default time-to-live for messages posted to this queue
  2. Max message size: different than the server default

We don't want these to collide with user-defined metadata, but we want users to be able to modify these values.

Design

PUT /v1/queues/{name}

Two changes are required here:

  • Ignore anything placed in the message body. PUT does not update metadata.
  • At the storage layer, have the queue controller's upsert operation leave metadata alone.

PUT /v1/queues/{name}/metadata

Used to update metadata. The queue body represents the new metadata.

PUT /v1/queues/{name}/metadata

Used to fetch the metadata.