Orion与QuantumLeap订阅正常，但CrateDB未生成对应数据表

1. 先核对订阅配置细节 #

• 确认notification.endpoint地址完全正确，必须指向QuantumLeap的通知接收接口（比如http://quantumleap:8668/v2/notify），注意端口、路径和部署环境的网络可达性
• 检查订阅的entities过滤规则：CALCULATION类型实体的type字段大小写必须完全匹配（FIWARE对大小写敏感，不能写成calculation）
• 确认订阅的attrs字段要么包含实体实际存在的属性，要么用*指定全量属性——如果实体无任何属性变化，QuantumLeap不会触发建表操作
• 排查throttling参数是否设置过高导致通知延迟，同时确认expires字段未过期

2. 查看QuantumLeap运行日志 #

• 直接拉取QuantumLeap的容器日志（比如执行docker logs quantumleap），重点关注：
  • 是否有接收OCB通知的日志条目，验证请求是否成功到达
  • 是否存在建表失败的错误信息（比如CrateDB连接异常、SQL语法不兼容）
  • 是否有实体数据格式报错（比如属性类型不匹配、CrateDB不支持的字段类型）
• 注意CrateDB版本兼容性：CrateDB 5.0.0属于较新版本，需确认当前使用的QuantumLeap版本是否适配5.x系列（部分旧版QuantumLeap仅支持到CrateDB 4.x）

3. 检查CrateDB侧状态 #

• 登录CrateDB控制台，执行查询语句SELECT * FROM information_schema.tables WHERE table_schema = 'fiware';（默认QuantumLeap使用fiware schema），确认表是否真的未生成
• 验证QuantumLeap所用数据库账户是否具备CREATE TABLE和INSERT权限
• 查看CrateDB日志，排查是否有连接拒绝、SQL执行失败的记录

4. 触发实体数据更新验证 #

• 手动发送PATCH请求修改CALCULATION类型实体的某个属性值，强制OCB发送新的通知
• 观察QuantumLeap是否接收到此次更新通知并尝试写入CrateDB——首次有效属性数据才会触发建表逻辑

5. 重置QuantumLeap元数据缓存 #

• 若以上步骤均无问题，可能是QuantumLeap内部元数据缓存异常：
  1. 停止QuantumLeap服务
  2. 清理本地缓存（文件缓存则删除对应目录；Redis缓存则清空相关键值）
  3. 重启QuantumLeap，重新创建订阅并触发实体属性更新

内容的提问来源于stack exchange，提问作者Galhrrera