RxDB 项目中 undefined 选择器在 SQLite 适配器中的行为分析

RxDB 作为一个跨平台的实时数据库，提供了多种存储适配器支持。在实际开发中，开发者可能会遇到不同适配器对查询选择器处理不一致的情况。本文将深入分析一个典型问题：在 MangoQuery 查询中使用 undefined 作为字段值的选择器时，为何在 SQLite 适配器中无法正常工作，而在 IndexedDB 适配器中却能返回预期结果。

问题现象

当开发者使用如下查询选择器时：

const selector = {
  radiator_id: radiatorId,
  replaced_valve_id: undefined
};

在 IndexedDB 适配器下能够正确返回目标文档（该文档中不存在 replaced_valve_id 字段），但在 SQLite 适配器下却无法返回任何结果。值得注意的是，如果移除 replaced_valve_id: undefined 这一条件，两个适配器都能正常工作。

技术背景分析

1. BSON 类型与 undefined 处理

在 MongoDB 生态中，undefined 作为一种特殊的 BSON 类型曾经被支持，但最新文档已将其标记为废弃。MongoDB 官方建议开发者迁移使用其他方式来表示字段不存在的情况。

2. RxDB 的跨领域通信机制

RxDB 设计需要支持跨领域通信（如与 Web Worker 交互），这一过程中会使用 JSON.stringify() 对查询进行序列化。众所周知，JSON.stringify() 会直接忽略值为 undefined 的属性，这导致查询条件在传输过程中丢失。

3. 不同适配器的实现差异

IndexedDB 适配器可能保留了更宽松的查询语义处理，能够隐式地将 undefined 解释为"字段不存在"的查询条件。而 SQLite 适配器则遵循了更严格的实现，直接忽略了这一条件，导致查询结果不符合预期。

解决方案与最佳实践

RxDB 维护者已经通过代码提交修复了这一问题，并添加了开发模式检查，禁止在查询中使用 undefined 值。开发者应采用以下标准方式来表达"字段不存在"的查询需求：

1. 使用 $exists 操作符：

const selector = {
  radiator_id: radiatorId,
  replaced_valve_id: { $exists: false }
};

2. 使用 $eq 操作符检查 null 值（如果业务逻辑允许）：

const selector = {
  radiator_id: radiatorId,
  replaced_valve_id: { $eq: null }
};

技术启示

这一案例揭示了几个重要的技术认知：

1. 序列化边界问题：在设计跨边界通信的系统时，必须考虑数据序列化带来的语义变化。undefined 在 JavaScript 中是一个明确的值概念，但在序列化后会丢失这一信息。

2. 数据库适配器一致性：为不同后端实现适配器时，应当建立明确的语义规范，确保相同查询在不同适配器下表现一致。

3. 渐进式弃用策略：对于废弃的功能，除了文档说明外，在代码层面添加开发时检查是更有效的迁移手段。

总结

在 RxDB 或其他数据库系统的使用中，开发者应当避免依赖 undefined 作为查询条件。这一实践不仅解决了当前适配器间的行为差异问题，也使代码更符合数据库查询的标准范式，提高了应用的健壮性和可维护性。理解底层技术实现细节，能帮助开发者写出更可靠的数据访问层代码。