From 788238d166c899ef999d52057863425510402f53 Mon Sep 17 00:00:00 2001 From: Michael Barz Date: Fri, 8 Apr 2022 23:34:36 +0200 Subject: [PATCH] address review feedback --- docs/ocis/adr/0019-file-search-index.md | 1 + .../adr/0020-file-search-query-language.md | 19 +++++-------------- 2 files changed, 6 insertions(+), 14 deletions(-) diff --git a/docs/ocis/adr/0019-file-search-index.md b/docs/ocis/adr/0019-file-search-index.md index 8c7d90914e..6780c6d427 100644 --- a/docs/ocis/adr/0019-file-search-index.md +++ b/docs/ocis/adr/0019-file-search-index.md @@ -31,6 +31,7 @@ Sharing adds more complexity because the index also needs to react to create, de * The Search Indexing Service should be replacable with more sophisticated technologies like Elasticsearch * Make use of the spaces architecture to shard search indexes by space * The Search Indexing Service needs to deal with multiple users accessing the same resources due to shares +* The Search Service should be compatible with different search indexing technologies ## Considered Options diff --git a/docs/ocis/adr/0020-file-search-query-language.md b/docs/ocis/adr/0020-file-search-query-language.md index 56156ce656..5ed7ad792c 100644 --- a/docs/ocis/adr/0020-file-search-query-language.md +++ b/docs/ocis/adr/0020-file-search-query-language.md @@ -27,7 +27,6 @@ From the users perspective, the interface to search is just a single form field ## Considered Options -* [Keyword Query Language](#keyword-query-language-kql) * [Simple Query](#simplified-query) * [Lucene Query Language](#lucene-query-language) * [Solr Query Language](#solr-query-language) @@ -35,33 +34,26 @@ From the users perspective, the interface to search is just a single form field ## Decision Outcome -Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)]. +Chosen option: [Simple Query](#simplified-query), because it is a suitable MVP. ### Positive Consequences -* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …] -* … +* We can do a quick implementation ### Negative consequences -* [e.g., compromising quality attribute, follow-up decisions required, …] -* … +* 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 ## Pros and Cons of the Options -### Keyword Query Language (KQL) - -Implement a search based on the Keyword Query Language (KQL), adopted from Sharepoint. - -* Good, because microsoft already uses it togethe with the GraphAPI -* Bad, because there is no go package - ### 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. * Good, because that covers 80% of the users needs * Good, because it is very straightforward +* Good, because it is a suitable solution for GA * Bad, because it is below the industry standard * Bad, because it only provides one search query @@ -97,7 +89,6 @@ 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://github.com/SharePoint/sp-dev-docs/blob/master/docs/general-development/keyword-query-language-kql-syntax-reference.md) * [Apache Lucene](https://lucene.apache.org/) * [Apache Solr](https://solr.apache.org/) * [Elastic Search](https://solr.apache.org/)