回移植HAPI FHIR Server HashmapResourceProvider修复后资源历史丢失问题排查

• 历史查询的过滤逻辑未适配
  v6.1.0的HashmapResourceProvider中getHistory方法可能存在默认过滤已删除资源的逻辑。回移植删除记录修复时，若只修改了删除操作的记录逻辑，未调整查询过滤规则，会导致查询历史时把所有关联已删除资源的版本全部过滤。需要检查getHistory中的过滤代码，确保即使资源已标记删除，仍保留所有历史版本（包括删除操作版本）。例如：

  // 错误的过滤逻辑（会移除所有关联已删除状态的版本）
  history = history.stream().filter(resource -> !isDeleted(resource)).collect(Collectors.toList());
  
  // 调整后的逻辑：保留所有版本，遵循FHIR规范返回完整历史
  

• 删除操作的版本存储逻辑错误
  HAPI FHIR的历史记录依赖版本号递增存储，删除操作需要生成新的资源版本并标记为已删除，再将该版本追加到历史列表中。若回移植时未正确维护版本列表（比如用替换而非追加操作），会导致旧版本被覆盖或丢失。检查删除方法中是否存在类似正确逻辑：

  // 正确操作：追加新的删除版本到历史列表
  List<IResource> history = myHistoryMap.computeIfAbsent(theId, k -> new ArrayList<>());
  history.add(deletedResourceVersion); // 而非替换整个列表
  

• 元数据DELETED_AT的关联与存储问题
  你对ResourceMetadataKeyEnum.DELETED_AT.get做了强制类型转换，但需确认删除操作时是否正确设置了该元数据。v6.1.0中，需确保元数据被正确关联到新生成的删除版本资源上，否则查询时会误判资源状态。检查删除逻辑中是否有：

  // 为新的删除版本设置DELETED_AT元数据
  ResourceMetadataKeyEnum.DELETED_AT.put((IAnyResource) deletedResourceVersion, new Date());
  

  同时确认v6.1.0的内存存储是否支持保留资源元数据，避免元数据在存储过程中丢失。

• Hashmap存储结构的兼容性问题
  v6.1.0的HashmapResourceProvider可能使用与修复版本不同的历史存储结构（比如版本列表的类型、键值定义）。回移植代码时若直接替换整个类，可能引入不兼容的存储操作，导致历史记录无法被正确读取。建议对比v6.1.0原类与修复版本的代码，只修改删除相关的逻辑片段，而非全盘替换类代码。

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