Database Reference
In-Depth Information
It will be easiest to understand the various options by trying examples of
each variation. Start with the simplest variant, a reference to a table as it
existed at a particular point in time:
$ START_TIME='1395214700000'
$ bq head ch11.time_lapse@$((${START_TIME} + 5 * 10 *
1000))
+-------+---------------+
| index | millis |
+-------+---------------+
| 2 | 1395214719589 |
| 4 | 1395214742932 |
| 0 | 0 |
| 1 | 1395214708049 |
| 3 | 1395214731135 |
+-------+---------------+
If you are wondering why the rows do not appear in order, keep in mind
that BigQuery does not guarantee a stable ordering of rows in a table. Only
the result of a query with an explicit ORDER BY clause has well-defined
ordering.
This is the table as it existed before the fifth row was added. You can see that
the value used for the timestamp is the timestamp that appears at index 5 in
the full table. The timestamp is encoded as the milliseconds since the UNIX
epoch (1970-01-01 00:00:00 UTC). If you pick a time that is earlier than
the table creation time, you will, unsurprisingly, get a NOT_FOUND error.
Instead of an absolute time, you could use a relative time by adding a leading
hyphen. The value specified as the relative time is interpreted as an offset in
milliseconds with respect to the current time. The absolute time is computed
by subtracting the offset from the current time.
$ date +%s; bq head ch11.time_lapse@-850000
1395215611
+-------+---------------+
| index | millis |
+-------+---------------+
| 2 | 1395214719589 |
| 4 | 1395214742932 |
Search WWH ::




Custom Search