openSUSE:Build Service Future Searches

通过 XPath 查询 vs 通过 URL 参数查询

给定以下示例模型（简化的 MySQL）

   CREATE TABLE `architectures` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `name` varchar(255) NOT NULL,
     `selectable` tinyint(1) DEFAULT '0',
     PRIMARY KEY (`id`),
   );

假设存在一个对应的 Ruby 模型和控制器，其中包含 'index'、'show' 和 'update' 操作。对于 XPath 使用，假定以下 XML 表示形式

   <?xml version="1.0" encoding="UTF-8"?>
   <architecture name="x86_64">
     <selectable>true</selectable>
     <enabled>true</enabled>
   </architecture>

OBS-2.x 的当前状态

可能的请求

1: GET /architecture&match="[@name=\"x86_64\" or selectable]"
2: GET /architecture&match="[$COMPLEX_PAGINATION and position()=$STH]"

优点

• XPath 真的非常强大！

缺点

• 需要在服务器（以及可能客户端）端使用 XPath 引擎
  • 引擎应缓存解析后的查询以提高速度（需要 MEM）
  • 需要 XPath 查询验证
• 需要 'arch' 表的层次化表示
  • 需要精确了解结构才能进行查询
  • 更改很麻烦
• JSON 支持需要自定义 XPath 引擎
• XPath 很复杂（即难以 'curl'）
• 可能比 URL 参数需要更多的引用和转义（只有 'values' 需要 URL 编码）

想要的状态（在遥远的银河系中）

可能的请求

1: GET /architectures&count=20&page=2  <- listing of archs (20-39)
2: GET /architectures&name=x86_64      <- index over 'name' wanted
3: GET /architectures&selectable=true

优点

• Rails 允许将表行（行）编组到 XML 或 JSON 中（需要视图）
• 这是每个人都在做的事情（可能不太有说服力）
• Rails 会取消编组并根据表模式进行验证（无需维护代码！）
• 分页参数 'count' 和 'page' 完美映射到 SQL 的 LIMIT_BY（速度非常快！）

缺点

• XPath 的 'or' 需要通过两次请求（2,3）或参数方案来模拟，例如

   GET /architectures&name=x86_64&name=i586&selectable=true

   For XPath "(name = 'x86_64' or name = 'i586) and selectable = 'true'"