Hi all, Following up on my May 8 self-introduction, I've completed the refined design document for GSOC-304 (Enhancing ThingsBoard Integration with IoTDB 2.x Table Mode). Posting it now, before community-bonding wraps on May 24, so feedback can land before coding starts on May 25.
Full document (16 pages, 12 sections + 3 appendices): https://drive.google.com/file/d/1jXMCwF_HVvCR5lHDIT_1pv1DiIZt8j5O/view?usp=sharing == TL;DR == The doc proposes concrete recommendations for the two open design questions called out by my mentor (Xuan Wang), with evidence from ThingsBoard schema/API/Rule-Engine and IoTDB Table Mode primitives: 1. Attribute table schema → recommend Option B (single `entity_attributes` table with `attribute_scope` as TAG). Backs the PoC's existing choice with cardinality math (Options A/B/C all represent ~150K logical attribute identities under typical multi-tenant deployment) + ThingsBoard's own SQL schema convention (scope and key are separate dimensions in `attribute_kv`) + native scope filtering. 2. Label handling → recommend Phase 1 does not mirror labels into IoTDB. Labels in current ThingsBoard are a singular optional entity field on Device/Asset (`HasLabel`, `private String label`), not a many-tag feature; they fit the existing entity DB. A contingent design (separate `entity_labels` table with current-state contract, no tombstones) is sketched in §5.4 in case the community wants a label index on the IoTDB side. The doc also includes a per-DAO Spring activation matrix in §6.0, the 12-week implementation plan aligned to mentor's phasing, a 5-test-case benchmark plan vs. IoTDB Tree / Cassandra / PostgreSQL / TimescaleDB, migration approach, and risks. Note on scope: the Wk 5 plan assumes the AttributesDao activation question (Q6 below) resolves to option (1) or (2). If maintainers prefer (3), AttributesDao moves to stretch and Wk 5 shifts to telemetry/latest polish. == Asks for community feedback (full context in §12 of the doc) == 1. Do you concur with Option B (scope-as-TAG) for the attribute table? See §4.10 for sub-questions on scope-constant naming, TTL, and TAG ordering. 2. Is the recommendation to keep labels out of IoTDB in Phase 1 acceptable, or should the design include `entity_labels` from day one? See §5.5. 3. Is `TTL='INF'` the right default for `entity_attributes` (latest-state metadata), or is there a real use case for a finite default TTL? 4. Any guidance on optimal TAG column ordering for IoTDB 2.x predicate pruning — `(tenant_id, entity_type, entity_id, attribute_scope, key)` or scope/key-first — or should I rely on `EXPLAIN ANALYZE` benchmarks during Wk 6? 5. Is the 5-backend benchmark scope (IoTDB Table / IoTDB Tree / Cassandra / PostgreSQL / TimescaleDB) the right set, or should TimescaleDB be optional? 6. (For ThingsBoard maintainers in particular) AttributesDao activation: do you prefer (1) a new `database.attributes.type` property mirroring the `ts.type` pattern (requires a small upstream patch), (2) Spring profile composition with the existing entity-DB switch, or (3) keep attributes in the entity DB for Phase 1 and treat AttributesDao as a stretch goal? See §6.0. Communication status on Q6: I have not yet engaged ThingsBoard maintainers directly on this question. Once this dev-list thread settles, I plan to cross-post a focused summary of Q6 to ThingsBoard Discussion #15296 and reach out via the ThingsBoard dev channel for maintainer-side input. If anyone here has working contacts with the ThingsBoard DAO reviewer team, introductions would be very welcome. I'd really value input on any of the above before May 25. Specific replies on questions 1, 2, and 6 are most time-critical, since they shape Phase 1 scope and Wk 5 deliverables. Thanks, Zihan Dai GitHub: https://github.com/PDGGK
