Hi alpass, I think it's a great idea, but we need to make sure that not include overhead for the normal cases if we don't use view.
On Thu, Sep 10, 2026 at 6:36 PM alpass <[email protected]> wrote: > Hi everyone, I'd like to start a discussion about the tree-to-table view > in the table model. > A tree-to-table view is created over a tree-model path prefix, and > exposes tree-model measurements as table columns. When such a view is > created without explicitly listing Field columns, the system scans the > subtree under the given prefixPath and generates one column > for each measurement that already exists. The structure of the > tree-to-table view is then fixed at creation time. > The scan runs only once, at creation. After that, any new measurement > created under prefixPath does not appear in the tree-to-table view. Users > have to run ALTER VIEW ... ADD COLUMN manually, or drop and recreate the > tree-to-table view. In deployments where > measurements are added continuously, this is hard to maintain and easy > to miss, and the missing columns lead to silently incomplete query results. > We propose adding an optional property, auto_sync_schema, to CREATE > VIEW. When it is set to true, the tree-to-table view keeps tracking > measurements newly created under its prefixPath and extends its schema > automatically. > CREATE VIEW view_01 (dev STRING TAG) WITH (auto_sync_schema = true) AS > root.db1.**; > The property defaults to false, so existing behavior is unchanged. It > only applies to tree-to-table views created without explicit Field columns; > specifying both Field columns and auto_sync_schema = true is rejected. It > is orthogonal to the existing RESTRICT option. > Only columns are added, never removed, so if a measurement is dropped > the column remains and queries on it return null. If a new measurement > conflicts with an existing column, either because it has the same name with > a different data type, or a name that differs only > in case, the column is skipped and a warning is logged, while the write > itself is not failed. > A template can also introduce new measurements. Activating a template on > a path, or adding a measurement to a template that is already activated, is > treated as a new measurement, and triggers the same schema extension in the > tree-to-table view. > One point worth calling out: to keep the tree-to-table view consistent > with the tree schema, the extension happens during series creation. If the > tree-to-table view cannot be updated, the series creation itself fails. > On impact, the write path is unchanged when no auto-sync tree-to-table > view matches the path; when one matches, one additional schema update is > performed. Query behavior and existing tree-to-table views are unaffected. > SHOW CREATE VIEW will display the new property. > Best regards, > Yaobin Chen > --- > 主题：[DISCUSS] 树转表视图自动检测新增测点并扩展结构 > 我想就表模型下的树转表视图发起一个讨论。 > 树转表视图创建在树模型的某个路径前缀之上，把树模型的测点暴露为表的列。当这样的视图在创建时不显式指定 Field 列时，系统会扫描该 > prefixPath 下的子树，为每一个已存在的测点生成一列。树转表视图的结构在创建时即固定。 > 该扫描只在创建时执行一次。此后，prefixPath 下新增的任何测点都不会出现在该树转表视图中。用户必须手动执行 ALTER VIEW ... > ADD COLUMN，或者删除并重建这棵树转表视图。在测点持续新增的部署场景下，这难以维护且容易遗漏，而缺失的列会导致查询结果静默不完整。 > 我们建议为 CREATE VIEW 增加一个可选属性 auto_sync_schema。当其设为 true 时，该树转表视图会持续跟踪其 > prefixPath 下新增创建的测点，并自动扩展自身结构。 > CREATE VIEW view_01 (dev STRING TAG) WITH (auto_sync_schema = true) AS > root.db1.**; > 该属性默认为 false，因此现有行为不变。它仅对未显式指定 Field 列的树转表视图生效；同时指定 Field 列与 > auto_sync_schema = true 会被拒绝。它与现有的 RESTRICT > 选项正交。只增加列，不删除列，因此若某个测点被删除，对应的列仍然保留，对该列的查询返回 > null。若新增测点与已有列冲突，无论是同名但数据类型不同，还是名称仅大小写不同，该列都会被跳过并记录一条告警日志，而写入本身不会失败。 > 模板同样可能引入新的测点。在某个路径上激活模板，或者向一个已被激活的模板中新增测点，都会被视作新增测点，并触发该树转表视图的同样结构扩展。 > 有一点值得单独说明：为了让树转表视图与树结构保持一致，扩展动作发生在序列创建过程中。如果该树转表视图无法更新，序列创建本身会失败。 > > 关于影响面，当没有任何开启自动同步的树转表视图匹配该路径时，写入路径不变；当存在匹配时，会额外执行一次结构更新。查询行为与已有的树转表视图不受影响。SHOW > CREATE VIEW 会展示该新增属性。 > Best regards, > Yaobin Chen
