# Understanding types

Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fdataprime%2Fuser-guide%2Ffoundations%2Funderstanding-types.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fdataprime%2Fuser-guide%2Ffoundations%2Funderstanding-types.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

## Goal[​](#goal "Direct link to Goal")

By the end of this guide you should be able to identify the data types used in DataPrime and understand how to work with them effectively in queries, including type conversions and casting.

***

## Why it matters[​](#why-it-matters "Direct link to Why it matters")

Every field in your logs, traces, or enriched data in DataPrime has a type. Whether it's a number, a timestamp, or a string of text, understanding types is critical for writing accurate queries, performing aggregations, and avoiding unexpected `null` results. If your logic doesn’t match the type, your query might look right—but silently fail.

***

## Supported types in DataPrime[​](#supported-types-in-dataprime "Direct link to Supported types in DataPrime")

Here’s a breakdown of the main types you’ll encounter and use:

| Type          | Description                                                                                    | JSON Representation                  |
| ------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------ |
| **string**    | UTF-8 encoded character sequences                                                              | `"hello world"`                      |
| **number**    | Integer or float. Max is `2^53`                                                                | `123`, `45.67`                       |
| **bool**      | Boolean value (`true`/`false`)                                                                 | `true`                               |
| **timestamp** | Nanosecond-precision point in time                                                             | `1609459200000000000`                |
| **interval**  | Time duration (`3h30m`, `5s`)                                                                  | `"3h30m"` (or number in nanoseconds) |
| **regexp**    | Regular expression used in filtering and matching                                              | `"/[a-z]+/"`                         |
| **null**      | 1. Absence of a value<br />2. Non-computable expression<br />3. `null` value of the JSON field | `null`                               |
| **array**     | Collection of primitive values of a single type                                                | `["a", "b", "c"]`                    |

Note

Intervals can be string or numeric (in nanoseconds), depending on context.

***

## What happens if types mismatch?[​](#what-happens-if-types-mismatch "Direct link to What happens if types mismatch?")

Types will raise an error prior to execution if there is a mismatch.

For example this query will show the error message below:

```
filter timestamp > '10'
```

When values are cast in an incompatible way, many functions and operations return `null` silently.

***

## Type-specific usage rules[​](#type-specific-usage-rules "Direct link to Type-specific usage rules")

* **Strings**: Use for free-text searches and `~`, `contains()`, etc.
* **Numbers**: Required for mathematical operations and aggregations like `avg`, `sum`.
* **Timestamps**: Combine with interval types for time math (e.g., `now() - timestamp > 5m`)
* **Intervals**: Use with time functions like `diffTime`, `addTime`.
* **Arrays**: Ensure consistent item types. Use functions like `arrayContains`, `arrayLength`.
* **Booleans**: Filter conditions and flags.
* **Null**: Any null used in a boolean condition is treated as `false`.

***

## Null semantics[​](#null-semantics "Direct link to Null semantics")

In DataPrime, `null` represents an undefined or missing value. It behaves similarly to SQL `NULL`, but with some important differences. A query will evaluate to `null` in the following cases:

* **Field does not exist** (i.e. the log has no `foo` field at all)

* **Field exists but is explicitly `null`** (i.e. `{foo: null}`)

* **Expression cannot be computed** This includes cases where a value cannot be converted or an operation fails. Examples:

  * `'foo':bool` → `null`
  * `create x from 'foo' | choose parseInterval(x) as value` → `value: null`
  * `extract '{"value":"foo"}' into target using jsonobject() | choose target.value + 1` → `null`

### Aggregations:[​](#aggregations "Direct link to Aggregations:")

Nulls are preserved in aggregation results unless the function ignores them.

* `aggregate collect(foo)` includes nulls in the output array unless specified with the `ignoreNulls` flag. See [documentation](https://docs-docusaurus.kinsta.page/dataprime/language-reference/functions-reference/aggregation/collect/.md).
* `aggreagte any_value(foo)` returns a non-null value if one exists.

### Joins:[​](#joins "Direct link to Joins:")

Rows with `null` in the join key do **not** match.

### Equality:[​](#equality "Direct link to Equality:")

* A non-existent key value is equal to null. If `foo` does not exist as a key in your logs then:
  <!-- -->
  ```
  foo == null // true
  ```
* Two non-existent key values are equal to each other. If `foo` and `bar` are non-existent keys then:
  <!-- -->
  ```
  foo == bar // true
  ```
* Two objects are equal if and only if all fields match exactly, including nulls.
  <!-- -->
  ```
  {"a": 1, "b": null} == {"a": 1, "b": null}  // true  

  {"a": 1} == {"a": 1, "b": null}             // false  
  ```
* Arrays must match element by element, including nulls.
  <!-- -->
  ```
  {"k": [null, 1]} == {"k": [null, 1]}  // true  

  {"k": [null]} == {"k": []}            // false  

  {"k": [1, 2]} == {"k": [2, 1]}        // false  
  ```

***

## Gotchas to watch for[​](#gotchas-to-watch-for "Direct link to Gotchas to watch for")

* Type mismatches often fail *silently* (especially in filters).
* Some fields may *appear* numeric but are strings (e.g., `status: "200"`).
* Intervals passed as strings must follow strict formatting (`1d2h3s` is valid, `3s1d` is not).
* Comparing a field to `null` is `true` if and only if the field is missing or explicitly `null`.
* Joins skip rows where the join key is `null`.
* Objects cannot be converted into strings. The only exception to this is `$d:string` which is done to support full-text manipulation using DataPrime functions.