北川です。
弊社では安否確認サービス2の他 kintone連携サービス の開発もしているということもあり、kintone REST API を頻繁に利用します。
中でも query という独自SQLのような機能をよく使うのですが、記法や SQL との差異をよく忘れるので BNF として記述しておこうと思い至りました。
また、BNF があると構文解析器も書きやすいですし文法チェックなど製品で役立つ機能開発に使うことができます。
W3S's EBNF での記述となります。文法のチェックには Railroad Diagram Generator を使用しました。
BNF
query ::= conditions? order-by-clause? limit-clause? offset-clause?
or-conditions ::= and-conditions ('or' and-conditions)*
and-conditions ::= parenethesized ('and' parenethesized)*
parenethesized ::= condition | '(' or-conditions ')'
condition ::= comp-condition | in-condition | like-condition
comp-condition ::= field comp-operator value
in-condition ::= field in-operator values
like-condition ::= field like-operator '"' string '"'
field ::= string ('.' string)?
comp-operator ::= '!'? '=' | '>' | '<' | '>=' | '<='
in-operator ::= 'not'? 'in'
like-operator ::= 'not'? 'like'
values ::= '(' value (',' value)* ')'
value ::= num | '"' string '"' | function
order-by-clause ::= 'order by' sortor (',' sortor)*
sortor ::= field ('asc' | 'desc')?
limit-clause ::= 'limit' num
offset-clause ::= 'offset' num
num ::= "任意の数値"
string ::= "任意の文字列"
function ::= "LOGINUSER()..."
注意点
- もちろん非公式である
- 細かい点で実際の仕様との差異はあるはず
補足
kintone REST API には「フィールド、システム識別子ごとの利用可能な演算子と関数」という制約がありますが、こういった意味的な正しさはBNFでは検査しないことにしています。
and と or では優先度を同じにしてしまうと結果が決定的にならないため、優先度を明示する必要があります。
再帰下降型の構文解析器を前提としているので左再帰にならないように意識しています。
トヨクモでは一緒に働いてくれるエンジニアを募集しております。
採用に関する情報を公開しております。
気になった方はこちらからご応募ください。
