From f437e8a2619e3b8bc41c4c9f93b20188ec2aa15c Mon Sep 17 00:00:00 2001 From: TzeYiing Date: Mon, 18 Apr 2022 15:51:22 +0200 Subject: [PATCH] Updated and fixed wording issues, added in warnings --- web/docs/guides/platform/logs.mdx | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/web/docs/guides/platform/logs.mdx b/web/docs/guides/platform/logs.mdx index 6329cbf1e71..d969e841c79 100644 --- a/web/docs/guides/platform/logs.mdx +++ b/web/docs/guides/platform/logs.mdx @@ -51,16 +51,19 @@ WHERE h.x_real_ip IS NOT NULL ![SELECT query example](/img/guides/platform/logs/select-query.png) -The log source, `edge_logs`, is required in order to formulate the SELECT query. Likewise, when querying the database logs, you would need to provide a table name reference as well. The list of supported product sources can be found under the **Sources** dropdown. - -Cross-source joining is currently supported. +The list of supported product sources can be found under the **Sources** dropdown. ### Unnesting Arrays -In the above example, in order to query across the metadata field, we need to unnest the field and add it as a join. When we inspect on an individual log by clicking on the log row, we can see that log metadata is stored as an array of objects. +To query the metadata in the above example, you can unnest the field and "join" the unnested data. Clicking on the log row shows that log metadata is stored as an array of objects. In order to query any value that is an array, we would need to `UNNEST()` that field and add it to the query as a join, thereby allowing us to reference the nested fields within the array. +:::caution + +Large projects may run into a `400 ORDER BY` memory limit error when querying with many unnested rows across large date ranges. If experiencing this error, consider reducing the number of unnested joins, or by reducing the queried date range. + +::: ### Functions @@ -69,14 +72,14 @@ You may have also noticed from the above examples that we are able to use certai #### Timestamp Behavior -Each log timestamp is stored as a `TIMESTAMP` data type. In order to utilize the `timestamp` field in a query, you would need to use the appropriate [timestamp function](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp) to query across the timestamp field. +Each log entry is stored with a `timestamp`. In order to utilize the `timestamp` field in a query, you can use the appropriate [timestamp functions](https://cloud.google.com/bigquery/docs/reference/standard-sql/timestamp_functions#timestamp). :::note -Although timestamps are rendered as unix microsecond timestamps in the Log Explorer, SQL queries should use the `TIMESTAMP` data type only. If using a unix timestamp value in a query, cast the value to a `TIMESTAMP` data type. +In the Log Explorer, timestamps are rendered as unix microsecond timestamps. SQL queries, however, should always use the `TIMESTAMP` data type. If you are using a unix timestamp value in a query, cast the value to a `TIMESTAMP` data type. ::: ## Templates -Templates are available to help shorten the time needed to craft these queries. There are examples for each complexity level, which can serve as a foundation for your custom queries. Templates are available under the **Templates** tab, or under the **Templates** Dropdown in the **Query** tab. +Templates are available to help craft you log queries. Templates are available under the **Templates** tab, or under the **Templates** Dropdown in the **Query** tab. \ No newline at end of file