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
word1contains "word1" in any fieldCase-insensitive
word1 word2contains "word1" and "word2" in any field- Case-insensitive
- White space is treated as AND implicitly.
word1 AND word2contains "word1" and "word2" in any fieldCase-insensitive
word1 OR word2contains "word1" or "word2" in any fieldCase-insensitive
word1 AND NOT word2contains "word1" but not "word2" in any fieldCase-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: id1field "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 exactlyCase-sensitive
source.type:"empower" AND data.sample.id:id1"source.type" is exactly "empower" and sample ID is exactly "id1"Case-sensitive
_exists_:source.typewhere the field "source.type" has any non-null value
!(_exists_:traceId)field "traceId" does not exist
file.size:>1000field "file.size" is greater than 1000
labels.name/value:somethingAbility 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:

🚧

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 TermsSearch 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 RangeSearch 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