Objects and Fields

The addressable member of a table is an object, whose values are stored within fields. What constitutes an object is user application-defined, but generally an object corresponds to a single time-stamped log record, event, transaction, or other entity. In some cases, it makes sense to store multiple records as a single object, such as an ERROR log record and its related stack trace. The following rules are used by the Logging service in managing objects:

•	No object ID: Unlike other storage services, Logging service objects do not have an object ID. Individual objects are not separately identifiable unless they are assigned a unique timestamp value.

•	Timestamp required: Every object must have a timestamp, assigned to the field called Timestamp. All timestamps are considered UTC values and must be given in the format:

YYYY-MM-DD hh:mm:ss.fff

Where YYYY-MM-DD is the date, hh:mm:ss is the time, and fff is a fractional time. The time elements are optional from right-to-left, and omitted elements default to zero. For example, the value 2015-09-03 14:01 is the same as 2015-09-03 14:01:00.000. Multiple objects can be assigned the same timestamp.

•	Dynamic fields: Fields are not predefined in the schema but are assigned dynamically as objects are added. Objects in the same table can have different fields.

•	SV scalars only: Logging objects are considered “flat” and must consist of simple scalar values. Multi-valued scalar and link fields are not currently supported.

•	Immutability: Objects cannot be modified once added. The only update operation supported by the Logging service is adding new objects.