-
Notifications
You must be signed in to change notification settings - Fork 40
KQ_Overview
Krile Query, KQはKrileにおいてツイートを選別するために使われるクエリ言語です。
主にタブの構成やミュート指定などに使われ、Krileの柔軟なフィルタシステムの根幹を成しています。
KQ は、以下のような形で記述されます。
from local where to contains us
from 以下の部分(local
)はソースクエリ、where 以下の部分(to contains us
)はフィルタクエリと呼ばれます。
ソースクエリはツイート取得元の指定、フィルタクエリはツイートの選別に利用されます。
ソースとフィルタを上手に指定することで、あなたの望むタイムラインを作ることができます。
ソースクエリとフィルタクエリは、明示的に指定がなければどちらかを省略することができます。
このため、 from track:"#krile"
や where text contains "くるる"
なども有効なクエリ表現となります。
このとき、ソースクエリを省略した場合には from local
が、フィルタクエリを省略した場合には where ()
が指定されたものとみなされます。
ただし、ミュートフィルタなど、フィルタクエリのみを指定する場面においては(当然ですが)省略はできません。
ソースクエリについては Sources を、フィルタクエリについては Expressions をご覧ください。
クエリの具体的なサンプルについては Examples をご覧ください。
Krile Query で記述された内容は、特にフィルタクエリについては Func<TwitterStatus, bool> と SQLに変換され実行されます。
この変換の制約上、一部表現が利用できない場合があったり、正常に動作しなかったり、フィルタの組み合わせによっては実行に長い時間がかかったりします。
一般的には、クエリは長ければ長いほど、複雑であればあるほど実行時間を要します。ただし、SQLを用いて問い合わせる場合は、インデックスが利用可能な項目についてはより速く実行が行えます。
たとえば、ユーザ問い合わせについて、 user contains "karno" よりも user == 15147941 や user == @karno の方が速く動作します。
これは、user contains "karno" が (select ScreenName from User where Id = status.UserId limit 1) LIKE '%karno%'
のようなSQLに変換されるのに対し、user == 15147941 や user == @karno が UserId = 14157941
のようなSQLに変換されるためです。
幸いなことに、生成されるSQLの非効率性はSQLiteの高いパフォーマンスが覆い隠してはいますが、KQによって生成されるSQLはほぼ「ひどいもの」です。このあたりについて腕に自信がある方はぜひpull requestをくださると幸いです。