mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-02-07 04:28:54 -06:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6611 from owncloud/kql-adr

Browse Source 
[docs-only] [adr] New decision was made to use kql
This commit is contained in:
Michael Barz
2023-06-26 10:50:51 +02:00
committed by GitHub
parent b00d221eac 93f1e381cf
commit a11b519833
1 changed files with 22 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/ocis/adr/0020-file-search-query-language.md
View File

@@ -1,15 +1,15 @@
---
title: "20. File Search Query Language"
date: 2022-03-18T09:00:00+01:00
date: 2022-06-23T09:00:00+01:00
weight: 20
geekdocRepo: https://github.com/owncloud/ocis
geekdocEditPath: edit/master/docs/ocis/adr
geekdocFilePath: 0020-file-search-query-language.md
---
* Status: proposed
* Deciders: @butonic, @micbar, @dragotin, @C0rby
* Date: 2022-03-18
* Status: accepted
* Deciders: @butonic, @micbar, @dragotin, @C0rby, @kulmann, @felix-schwarz, @JammingBen
* Date: 2023-06-23
## Context and Problem Statement
@@ -28,6 +28,7 @@ From the users perspective, the interface to search is just a single form field
## Considered Options
* [KQL - Keyword Query Language](#keyword-query-language)
* [Simple Query](#simplified-query)
* [Lucene Query Language](#lucene-query-language)
* [Solr Query Language](#solr-query-language)
@@ -35,19 +36,31 @@ From the users perspective, the interface to search is just a single form field
## Decision Outcome
Chosen option: [Simple Query](#simplified-query), because it is a suitable MVP.
Chosen option: [KQL - Keyword Query Language](#keyword-query-language), because it enables advanced search across all platforms.
### Positive Consequences
* We can do a quick implementation
* We can use the same query language in all clients
### Negative consequences
* We cannot specify terms or other search criteria
* We will need to find a good point in time to use a query language before we start working around it
* We need to build and maintain a backend connector
## Pros and Cons of the Options
### Keyword Query Language
The Keyword Query Language (KQL) is used by Microsoft Share Point and other Microsoft Services. It uses very simple query elements, property restrictions and operators.
* Good, because we can fulfill all our current needs
* Good, because it is very similar to the used query language in iOS
* Good, because it supports date time keywords like "today", "this week" and more
* Good, because it can be easily extended to use "shortcuts" for eg. document types like `:presentation` which combine multiple mime types.
* Good, because it is successfully implemented and used in similar use cases
* Good, because it gives our clients the freedom to always use the same query language across all platforms
* Good, because Microsoft Graph API is using it, we will have an easy transition in the future
* Bad, because we need to build and maintain a connector to different search backends (bleve, elasticsearch or others)
### Simplified Query
Implement a very simple search approach: Return all files which contain at least one of the keywords in their name, path, alias or selected metadata.
@@ -90,6 +103,7 @@ Elasticsearch provides a full Query DSL (Domain Specific Language) based on JSON
* [Search API](0018-file-search-api.md)
* [Search Indexing](0019-file-search-index.md)
* [KQL](https://learn.microsoft.com/en-us/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference)
* [Apache Lucene](https://lucene.apache.org/)
* [Apache Solr](https://solr.apache.org/)
* [Elastic Search](https://solr.apache.org/)