Search Query Examples and Results
This page describes Search query examples (and their results) that you can create using the Tetra Data Platform (TDP). For information about using the TetraScience API to run searches, see the TetraScience API Documentation.
You can enter text directly in the Search bar to search. Results that include Intermediate Data Schema (IDS) output files also return the associated RAW input files.
When running searches, keep in mind the following:
- If you search without specifying a field, then the value is case-insensitive.
- If you search for a specific field, then the value you enter must be the exact value.
Reserved Characters
The Search feature in the Tetra Data Platform recognizes these reserved characters:
Reserved Characters
Reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /
To use any character which functions as an operator in the query itself, use a leading backslash to escape them.
For example, to search for (1+1)=2, you must enter the query as:
\(1\+1\)\=2
The escape characters are dropped when viewed on the web, and should also be escaped.
Search Text Examples and Explanation
This table provides Search text examples and explains what the search process is when searching through the files.
If you enter this Search text, | then search every file that... | Notes |
---|---|---|
word1 | contains "word1" in any field | Case-insensitive |
word1 word2 | contains "word1" and "word2" in any field | - Case-insensitive - White space is treated as AND implicitly. |
word1 AND word2 | contains "word1" and "word2" in any field | Case-insensitive |
word1 OR word2 | contains "word1" or "word2" in any field | Case-insensitive |
word1 AND NOT word2 | contains "word1" but not "word2" in any field | Case-insensitive |
"word1 word2" | contains "word1 word2" in order in any field | - Case-insensitive -This behavior changes if you provide a specific field. |
data.sample.id: id1 | field "data.sample.id" is exactly "id1" | - Case-sensitive - If a field is mapped as a "keyword" type, then you must perform an exact match. A "contains" search will not work. |
data.sample.id:"fake-id1" | field "data.sample.id" is exactly | Case-sensitive |
source.type:"empower" AND data.sample.id:id1 | "source.type" is exactly "empower" and sample ID is exactly "id1" | Case-sensitive |
_exists_:source.type | where the field "source.type" has any non-null value | |
!(_exists_:traceId) | field "traceId" does not exist | |
file.size:>1000 | field "file.size" is greater than 1000 | |
labels.name/value:something | Ability to search on Labels from the Search bar |
Plain Text Processing Examples
Plain text entered in the Search bar is analyzed using OpenSearch's built-in Tokenizers. Word boundaries are determined based on the Unicode Text Segmentation algorithm, as specified in Unicode Standard Annex #29.
This means that any searches that contain spaces, hyphens, plus signs, and some other common symbols are broken down into terms; however, underscores are not.
For this sentence example:
The 2 QUICK Brown-Foxes jumped_over the lazy dog's bone.
The sentence is broken down into the following terms:
[ The, 2, QUICK, Brown, Foxes, jumped_over, the, lazy, dog's, bone ]
This may make exact-match searches unpredictable.
The following UUID example is trying to match an exact ID that includes hyphens:
576fd742-c1a6-4fb4-9ecb-398d53e4addb
This will match any data, including the following:
"576fd742", "c1a6", "4fb4", "9ecb", "398d53e4addb"
We recommend that when you want to query for an exact match for such a value, you should add quotes around the search string, as follows:
"576fd742-c1a6-4fb4-9ecb-398d53e4addb"
This causes OpenSearch to ignore any word boundaries and generate a more appropriate search result. However, this behavior exists for "free-text" searches only. Searches on exact fields are analyzed based on that particular field's type. For example, this query will use the Keyword tokenizer, because the field is a keyword type:
source.type.executionId: 576fd742-c1a6-4fb4-9ecb-398d53e4addb
By default, the Keyword tokenizer does not adhere to the same word boundaries rules as the Standard tokenizer. An exact-match query without quotations works as expected.
Nested Types
OpenSearch nested field types allow arrays of objects to be indexed in a way that they can be queried independently of each other. You can search for OpenSearch nested field types either in the Search bar or Query DSL queries.
For more information about searching for nested field types in the TDP, see How to Apply Filters to Search by Schema Data and Search by Using Query DSL. For more information about nested field types, see Nested field type in the OpenSearch documentation.
Wildcard Searches
Don’t use a wildcard prefix (*
) in searches. Instead, do either of the following:
- In the Search bar, enter either parts of a file path (separated by spaces), or a complete file path.
- Run a Query DSL query by using the Label & Advanced Filters menu
IMPORTANT
Queries that include wildcards aren’t as effective, take longer to run, and require more computing resources.
Group Search Terms Examples
You use () parentheses to group words or operations.
Group Search Terms | Search Result |
---|---|
word1 AND (word2 OR word3) | case-insensitive contains "word1" and one of "word2", "word3" in any field. |
status:(active OR pending) title:(full text search) | case-sensitive "status" field that is either "active" or "pending", or "title" field that is any of "full", "text", "search". |
Specify a Range Examples
You can specify ranges for: date, numeric, or string fields. You specify inclusive ranges with square brackets [min TO max], and exclusive ranges with curly brackets {min TO max}.
Specified Range | Search Result |
---|---|
date:[2021-01-01 TO 2021-12-31] | All dates in 2021 |
count:[1 TO 5] | Numbers 1..5 |
tag:{alpha TO omega} | Tags between alpha and omega, excluding alpha and omega |
count:[10 TO *] | Numbers from 10 upwards |
date:{* TO 2012-01-01} | Dates before 2012 |
count:[1 TO 5} | Numbers from 1 up to but not including 5 |
Updated 4 months ago