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
Create ORM tables for device_info, device_metrics_wide, device_metrics_narrow and metric_catalog.
764
+
765
+
TODO - 1 this method is currently called at startup after connection and will attempt to create tables each time.
766
+
We should optimize this to only attempt to create tables if we detect they don't exist, or if we detect a schema change that requires a refresh.
767
+
We can use SQLAlchemy's inspection/reflection capabilities to check for existing tables and columns before attempting to create them,
768
+
and we can also track the expected schema in the class to detect when a refresh is needed.
769
+
770
+
2 To handle multiple protocols each with their own unique registries, with potentially multiple devices per protocol, we need to change this method to
771
+
create wide table names based on the specific protocol name as seen in a given settings section. This requires a new protocol_settings method to
772
+
return a list of active scraper protocols to support (based on settings). TSDB will loop through those protocols and create mappings to table names
773
+
for each protocol based on the active registry map for that protocol. The required columns for each protocol based table will be created from device
774
+
level registry scans which will then be blended together to one column list per protocol. Narrow table does not need to be changed since it is designed to be
775
+
dynamic and handle any metric with the metric name as a key. Metric catalog needs to be updated to include device_info_id to track which metrics
776
+
belong to which protocol/device for the dynamic table creation. Device info table also needs to be updated to include protocol to link devices to
777
+
specific protocols and registries. Probably a Protocol table will be needed to track protocol names and link to device info and metric catalog.
778
+
779
+
3 Narrow table creation should handle ASCII in a separate text column with dictionary compression, and the metric_catalog
780
+
should track which metrics are ASCII to know which values to put in the ASCII column vs the value column.
781
+
782
+
4. Rollup logic also needs to be updated to handle multiple protocols/devices with different registries and metric sets,
783
+
and to know which tables to pull from for rollups based on the protocol/device of the incoming data.
784
+
This will employ a device_info_id column in the metric_catalog to link metrics to specific protocol/device tables,
785
+
and the rollup manager needs to be aware of this when creating rollup views and policies.
786
+
787
+
5. Backlog and flush logic also need to be updated to handle multiple protocol/device tables and to know which table
788
+
to write to based on the protocol/device of the incoming data.
789
+
790
+
For now, we can assume a single static registry map and a single wide table structure for simplicity.
0 commit comments