> ## Documentation Index
> Fetch the complete documentation index at: https://docs.allium.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Metadata Columns

> More info about table metadata columns.

Metadata columns are identified with a `_` prefix to the column name and is often data about the data transformation process, rather than of the blockchain data itself.

## `_updated_at` & `_created_at`

Some tables include the columns `_updated_at` & `_created_at`. These columns are currently *not officially supported*, so treat them as *experimental* if used in a prod environment.

The general behavior of these columns are:

1. `_created_at` is populated when a record is first created. The value does not change thereafter, unless a full refresh of the table is done.
2. `_updated_at` is populated when a record is first created, and at all subsequent updates to any column in the table. The value starts out equivalent as `_created_at`.
3. Caveats about `_updated_at`:
   a. These timestamps represent changes in our primary database, which is Snowflake us-central1 or in the Allium App. It does not reflect when changes are made in our replicated regions.
   b. It can be updated even if there's no change to the record content. We sometimes do repeated upserts to the same record.
   c. There is no guarantee between the relationship of `_updated_at` and any time-related column in the table (e.g. `block_timestamp`).
   d. In most cases, `_updated_at` occurs shortly after `block_timestamp`, depending on the latency of our data pipeline, but *this is not always the case*.
   e. `_updated_at` can be updated significantly later than `block_timestamp` in cases such as (non-exhaustive):
   * the table is recreated (full refreshed)
   * patching old data on the table via upserts (`_updated_at < _created_at` )
   * patching missing data on the table (`_updated_at == _created_at` )

If you use these columns for pulling data incrementally from Allium, make sure to account for the possible behaviors of the `_updated_at` & `_created_at`.

## `_changed_since_full_refresh`

Some tables include the column `_changed_since_full_refresh`.

The general behaviour of this column is:

1. `_changed_since_full_refresh` is set to `false` when a table is first created or full refreshed.
2. `_changed_since_full_refresh` is set to `true` for any record that is added or updated after the initial table creation, or after a full refresh.

We **do not** recommend using `_changed_since_full_refresh` for pulling data incrementally from Allium as you will re-pull a growing amount of the same records on each subsequent run.
For example, a record that has `_changed_since_full_refresh = true` from 2024 will remain that way until the table is full refreshed again.