Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

User-friendly operators

未关闭
  • 哪里不对？
#356 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

已经有一个关联 PR 被合并了。

  • #2109 来自 @nuclearcat —— 已合并

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
mongodb, python
领域
api, backend, cli

调研方向

首先跟踪 issue 中描述的 kci 命令行查询解析和 API URL 运算符处理，然后参考 MongoDB 查询运算符进行审查。完成的更改应具有范围明确的运算符和语法设计，处理组合运算符以及相关的 CLI 或属性名称约束，并使示例查询按预期运行。

由索引模型根据 Issue 内容生成。

描述

The current syntax for operators on the command line is the same as in the API URLs, with a __ separator between the attribute name and an operator. For example, to count the number of kernel revisions (checkout nodes) since the beginning of the Early Access phase:

$ ./kci node count created__gt=2023-09-04 name=checkout
38

This works, however there are a few things that could be improved:

Combining operators doesn't work

This should return the number of nodes for the 1-day period, but instead it only takes into account the 2nd query parameter:

$ kci node count created__gt=2023-09-04 created__lt=2023-09-05 name=checkout
166
Deal with attributes that have __ in their name

Some test suites might well have __ in their name or particular jobs might generate custom data including it in their attributes. While we could make it invalid and the API would be rejecting such data, we could also look for other ways to encode the operators in the URLs. At the very least, we could just make it invalid to name attributes that end with an operator name. For example, foo_bar would still be valid, and even foo__bar__baz, but not foo_gte or foo_bar_lt as gte and lt as known operators.

Consider additional operators

The current 4 operators were added out of necessity for the initial use-cases we had. A fully-fledged system would need to be able to deal with a broader range of use cases and as such more operators are likely to be required. See the list of MongoDB operators as a reference, they could all be implemented very easily since internally the API uses MongoDB (at least the comparison ones).

Probably we could already just add the ne (not equal) operator to the list, in fact it's quite surprising we got this far without needing it.

Command-line syntax

While some improvements can be made on the API side to provide features and define any constraints with attribute names, the CLI syntax offered by kci could also be made simpler. Right now, it's quite easy to forget one underscore and doing created_lt=2024 will not match anything as that's looking for an attribute called created_lt.

If we wanted to keep it as-is and just pass the search parameters to the URL, we could have a check in kci if the attribute name ends with a known operator and print a warning to the user.

On top of this, we could also provide some symbols such as <, <=, == etc. as equivalents to the operator acronyms. A sample command line would then look like this:

$ kci node count "created > 2023-09-04" "created <= 2023-09-05" name=checkout

Please note that this would involve lots of characters that aren't very usable on the command line: < and > are used for redirecting streams, ! is a magic character in most shells to do things like running a previous command and = is used by parsers for arguments that take a value. So while making the queries more human-readable on the CLI is a good idea, it doesn't seem obviously better to just use these symbols. One option would be to create an interactive parser e.g. kci shell and then any characters could be used without interfering the main OS shell.

主要语言
Python
星标
10
派生
21
平均合并
22 分钟
30 天内合并 PR
1

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

kernelci/kernelci-api 的其他 Issue

查看 kernelci/kernelci-api 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。