You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use actual data for date predictions if available, not partition names. (#37)
* Use actual data for date predictions if available, not partition names.
Fixes#30
This commit limits the functionality to tables with single-column primary keys.
* More text to the README about insertion_date_query
* Set to v0.3.0 unstable
* Rename insertion_date_query to earliest_utc_timestamp_query
* Use SQL quoting in the examples
* Fix spelling error
SELECT UNIX_TIMESTAMP(created) FROM table1 WHERE id > ? ORDER BY id ASC LIMIT 1;
83
92
table2:
84
93
partition_period:
85
94
days: 30
95
+
earliest_utc_timestamp_query: >
96
+
SELECT UNIX_TIMESTAMP(created) FROM table2 WHERE id > ? ORDER BY id ASC LIMIT 1;
86
97
table3:
87
98
retention:
88
99
days: 14
100
+
earliest_utc_timestamp_query: >
101
+
SELECT UNIX_TIMESTAMP(created) FROM table3 WHERE id > ? ORDER BY id ASC LIMIT 1;
89
102
table4: {}
90
103
```
91
104
105
+
The `earliest_utc_timestamp_query` entries are optional SQL queries that are run during partition map analysis to determine the eact timestamp of the earliest entry in each partition. If you configure such a query for a table, it must return a single row and column, specifically the epoch timestamp in UTC of the earliest entry the partition. There is expcected a single `?` entry which will be replaced with the partition value of that partition.
106
+
92
107
For tables which are either partitioned but not yet using this tool's schema, or which have no empty partitions, the `migrate` command can be useful for proposing alterations to run manually. Note that `migrate` proposes commands that are likely to require partial copies of each table, so likely they will require a maintenance period.
0 commit comments