From 79cc71dfba36523eab97fae2ea9b60f349d89814 Mon Sep 17 00:00:00 2001 From: PragmaTwice Date: Sun, 2 Jun 2024 23:51:36 +0900 Subject: [PATCH] fix --- blog/2024-06-02-kqir-query-engine/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/2024-06-02-kqir-query-engine/index.md b/blog/2024-06-02-kqir-query-engine/index.md index b9e45a42..8770c660 100644 --- a/blog/2024-06-02-kqir-query-engine/index.md +++ b/blog/2024-06-02-kqir-query-engine/index.md @@ -59,7 +59,7 @@ Given this similarity, supporting SQL should not increase significant challenges Secondly, SQL enjoys broader usage and is familiar to more individuals. It is simpler to learn at the syntax level. While developers may need time to understand RediSearch query syntax, adapting to a new SQL database often requires less effort. Furthermore, SQL offers robust support for various query features, enhanced expressive capabilities (like JOINs, subqueries, aggregations). -Finally, RediSearch query syntax suffers from some historical designs. For example, the operator precedence of AND and OR (represented by space and `|` operator in RediSearch queries) varies across different dialect versions (dialect 1 vs. dialect 2). This tribal knowledge might lead users to prefer established query languages. +Finally, RediSearch query syntax suffers from some historical designs. For example, the operator precedence of AND and OR (represented by space and `|` operator in RediSearch queries) [varies across different dialect versions](https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/query_syntax/#basic-syntax) (dialect 1 vs. dialect 2). This tribal knowledge might lead users to prefer established query languages. To sum up, we believe that supporting SQL as a querying language would be a good decision.