mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-05-24 16:41:35 -04:00
Code Issues Packages Projects Releases Wiki Activity

address review feedback

Browse Source
This commit is contained in:
Michael Barz
2022-04-08 23:34:36 +02:00
parent 12b59175a5
commit 788238d166
2 changed files with 6 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/ocis/adr/0019-file-search-index.md
View File

@@ -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

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

@@ -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/)