Skip to content

Commit

Permalink
docs: add content
Browse files Browse the repository at this point in the history
  • Loading branch information
@panshuai111
panshuai111 committed Oct 19, 2023
1 parent 09bbf1b commit d75377d
Showing 1 changed file with 21 additions and 13 deletions.
34 changes: 21 additions & 13 deletions docs/design_docs/search_language.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,15 @@ Multiple expressions can be connected using boolean operators.

### Solution 2: Using DSL for Search

#### Synopsis
#### Mapping concepts across SQL and Elasticsearch

| SQL | Elasticsearch | Description |
|--------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| column | field | In both cases, at the lowest level, data is stored in named entries, of a variety of data types, containing one value. SQL calls such an entry a column while Elasticsearch a field. Notice that in Elasticsearch a field can contain multiple values of the same type (essentially a list) while in SQL, a column can contain exactly one value of said type. Elasticsearch SQL will do its best to preserve the SQL semantic and, depending on the query, reject those that return fields with more than one value. |
| row | document | Columns and fields do not exist by themselves; they are part of a row or a document. The two have slightly different semantics: a row tends to be strict (and have more enforcements) while a document tends to be a bit more flexible or loose (while still having a structure). |
| table | index | The target against which queries, whether in SQL or Elasticsearch get executed against. |

#### Synopsis of SQL

```sql
SELECT [TOP [ count ] ] select_expr [, ...]
Expand All @@ -101,35 +109,35 @@ SELECT [TOP [ count ] ] select_expr [, ...]
[ PIVOT ( aggregation_expr FOR column IN ( value [ [ AS ] alias ] [, ...] ) ) ]
```

#### Mapping concepts across SQL and Elasticsearch
Support table: `resources`

| SQL | Elasticsearch | Description |
|--------|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| column | field | In both cases, at the lowest level, data is stored in named entries, of a variety of data types, containing one value. SQL calls such an entry a column while Elasticsearch a field. Notice that in Elasticsearch a field can contain multiple values of the same type (essentially a list) while in SQL, a column can contain exactly one value of said type. Elasticsearch SQL will do its best to preserve the SQL semantic and, depending on the query, reject those that return fields with more than one value. |
| row | document | Columns and fields do not exist by themselves; they are part of a row or a document. The two have slightly different semantics: a row tends to be strict (and have more enforcements) while a document tends to be a bit more flexible or loose (while still having a structure). |
| table | index | The target against which queries, whether in SQL or Elasticsearch get executed against. |

support table: `resources`
Support column: `content`,`cluster`,`apiVersion`,`group`,`namespace`,`name`,`label`,`label.key`,`label.val`,`annotation`,`annotation.key`,`annotation.val`.

support column: `content`,`cluster`,`apiVersion`,`group`,`namespace`,`name`,`label`,`annotation`
Example:

example:
Match exactly:

```sql
SELECT * from resources WHERE cluster=tes1
```

Full text query:

```sql
SELECT * from resources WHERE content CONTAINS 'test1'
```

## Solution Comparison

| Solution | Advantages | Disadvantages |
|----------|------------------------------------------------|-------------------------------------------------------|
| DSL | simple searches are easier to get started with | complex searches require learning the relevant syntax |
| SQL | no need to learn an additional search language | writing simple searches can sometimes be more verbose |
| DSL | Simple searches are easier to get started with | Complex searches require learning the relevant syntax |
| SQL | No need to learn an additional search language | Writing simple searches can sometimes be more verbose |

# Reference
* [Search query syntax - Sourcegraph docs](https://docs.sourcegraph.com/code_search/reference/queries)
* [Understanding GitHub Code Search syntax - GitHub Docs](https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax)
* [Query DSL | Elasticsearch Guide [8.10] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html)
* [Basic Editing in Visual Studio Code](https://code.visualstudio.com/docs/editor/codebasics#_advanced-search-options)
* [SQL | Elasticsearch Guide [8.10] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-sql.html)
* [Pulumi Insights: Resource search | Pulumi Docs](https://www.pulumi.com/docs/pulumi-cloud/insights/search/)

0 comments on commit d75377d

Please sign in to comment.