PDGGK opened a new pull request, #117: URL: https://github.com/apache/iotdb-extras/pull/117
## Retention / TTL Physical retention was never documented for this module, even though the shipped schema already declares `telemetry` with `WITH (TTL=DEFAULT)`. This adds a **Retention / TTL** section to the README covering what an operator actually has to do: - IoTDB Table Mode expresses TTL as a table property in **milliseconds**, and the accepted spellings are narrow: a concrete retention is a bare, unquoted long (`TTL=604800000`); never-expire is the **quoted** string `TTL='INF'` (the form `entity_attributes` and `telemetry_latest` already ship with); `TTL=DEFAULT` inherits the database default. An unquoted `TTL=INF` is parsed as an identifier and rejected, and any other quoted value — a quoted number (`'604800000'`) or a duration (`'7d'`) — fails with `ttl value must be 'INF' or a long literal`. All four forms were checked against a 2.0.8 container. - A concrete retention is set either at create time (`CREATE TABLE telemetry (...) WITH (TTL=604800000)`) or at runtime (`ALTER TABLE telemetry SET PROPERTIES TTL=604800000`), and read back from `SHOW TABLES` or from `information_schema.tables`, where the column has to be quoted as `"ttl(ms)"`. - `telemetry_latest` stays `TTL='INF'` deliberately: it holds one row per identity and is the authority for a latest value, so expiring it would drop the latest reading while history remained. It also records a limitation that was implicit in the code and easy to misread: ThingsBoard's `TimeseriesDao.save(..., long ttl)` carries a **per-data-point** TTL, but IoTDB retention can only be expressed **per table**, so the two cannot be reconciled faithfully. The module uses that argument (with `iotdb.defaultTtlMs`) only for ThingsBoard's storage data-point accounting, never as an instruction to expire rows. `IoTDBTableTtlIT` pins the operator paths against a real `apache/iotdb:2.0.8-standalone` container: the schema bootstrap resolving `TTL=DEFAULT`, the shipped `TTL='INF'` on `entity_attributes` reading back as `INF`, `ALTER TABLE ... SET PROPERTIES TTL=<ms>` and back to `DEFAULT`, and a `CREATE TABLE ... WITH (TTL=<ms>)` read back exactly. It asserts the TTL **property mechanism** only — not physical row eviction, which is asynchronous and compaction-driven and so is not deterministic inside a test. ## README accuracy Writing that section surfaced that the rest of the README still describes the module as it was several changes ago, so this brings it back in line with the code: - Scope, the configuration table and Status said time-bucketed aggregation was **not implemented** and that aggregation, latest telemetry and the attribute DAO were **outside the current scope**. All three are implemented, so those sections now describe the three DAOs and their independent selectors. - The `iotdb.ts.experimental-raw-only` row now says what the flag really does: the name predates aggregation support and is kept for compatibility, but it is the opt-in for the backend as a whole rather than a raw-only switch. - The latest-telemetry limitation bullet said key discovery returns an empty list. `findAllKeysByEntityIds` reads `DISTINCT key` from both `telemetry` and the `telemetry_latest` overlay; only the batch `findLatestByEntityIds` deferral remains, and that bullet is kept. - The overview said the integration tests cover the write path; they cover write, read, aggregation, latest telemetry, attributes and now retention. ## Tests Full module build is green on JDK 17: 190 unit tests and 54 container integration tests, including the two new TTL tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
