## Description
First draft of the Snowflake getting started documentation.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6936
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
Co-authored-by: Brandon Martin <40686+codedmart@users.noreply.github.com>
Co-authored-by: Rob Dominguez <24390149+robertjdominguez@users.noreply.github.com>
GitOrigin-RevId: 8500e81111f3200634ee9183d710718f0463f419
For context: https://github.com/hasura/graphql-engine-mono/pull/6931
This PR makes some revisions that I had originally intended to be in the code, but due to some mixup, was refactored without discussion. @vijayprasanna13 and I synced up to try and make a decision about how to resolve it, but ultimately wanted to get more eyes on it to weigh in.
For context, when I refer to "premade selectors" I am talking about [this file](8a9264b14c/console/src/features/hasura-metadata-api/selectors.ts (L34))
And when I refer to "utility functions" (or metadata utility functions), I am talking about [this file](8a9264b14c/console/src/features/hasura-metadata-api/utils.ts (L38))
The changes I am suggesting here mostly about maintaining (IMHO) clearer separation of concern for selectors vs utility functions, and improving DX.
Here's how I see it high level:
In other words, I want to avoid using pre-made selectors within a custom selector as it creates a pattern of multiple layers of curried functions and beings to (IMHO) look confusing and blur the separation of concern.
What I am proposing is that we have a convention of doing either
1) Developer wants the entire table object of a specific table. They can easily do this using one of the **premade** selectors and pass directly into `useMetdata()`:
```ts
const { isLoading, data: metadataTable } = useMetadata(
MetadataSelectors.findTable(dataSourceName, table)
);
```
2) Developer wants to get a specific piece of information on a specific table. They can leverage the `findMetadataTable()` utility function within a custom inline selector like this and avoid extra currying and double selector confusion:
```ts
const { isLoading, data: savedComment } = useMetadata(
m => MetadataUtils.findMetadataTable(dataSourceName, table, m)?.configuration?.comment
);
```
This is somewhat of a stylistic preference, but also one that I think makes a cleaner separation of concern in the way we are building the api and supportive pieces. In other words, premade selectors are _always_ a selector and not used to compose other selectors. It also makes available utility functions that are easy to pull of the shelf to do common metadata tasks whether in the scope of `useMetadata` or not.
## Simpler Approach?
We could also just go with **Flow # 2** and eliminate the premade selectors. The dev would then pass a custom selector into `useMetadata()` and if they prefer, use a utility function to support their task.
With that aside, whatever the team agrees makes more sense, I will gladly get on board with, but I wanted to make my case here : )
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7095
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
GitOrigin-RevId: 7ecc2db172def0d2f714cbbb2f95a4b56a528093
## Description
This PR updates the doc around webhook based authentication for websocket connections explaining how exactly `Cache-Control` and `Expires` headers function.
## Changelog ✍️
__Component__ : server
__Type__: bugfix
__Product__: community-edition
### Short Changelog
update docs around webhook based authentication for websocket connection
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7135
Co-authored-by: Sean Park-Ross <94021366+seanparkross@users.noreply.github.com>
GitOrigin-RevId: ab873c394aad3a94d1a3affa483363f28ab77693
## Description 🔖
This PR adds snapshot testing to e2e tests. The goal is to avoid regressions that involve metadata by checking:
- the payload of requests sent
- the metadata after modification (only relevant part of the metadata)
We implemented this feature for one test, `actionWithTransform.e2e.test.ts` but this approach can be potentially used for other tests as well.
## Review checklist. 📋
- [ ] Run e2e tests
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7058
Co-authored-by: Varun Choudhary <68095256+Varun-Choudhary@users.noreply.github.com>
GitOrigin-RevId: 618147fad3f7d6849a0815b16c077efddef751ca
## Description
This PR fixes the test `actionWithTransform.e2e.test.ts`, failing only on CI (not on local builds). I've added some timeout when clearing the text areas; this probably fixes some issues due to debounce time.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7109
GitOrigin-RevId: 30efbc32bb804cc11d3e4af0f70b552512c6ded1
This PR implements the remaining codecs for table permissions. However the codec for boolean expressions delegates to Aeson instances because Autodocodec doesn't currently have the necessary feature to write a codec for boolean expressions that will reliably parse valid data.
Boolean expressions are objects with keys like `_and`, `_or`, `_exists`, or `<field name>`. The parsing rules for each value depend on the key, so we need to be able to select different codecs for each key. We could do that with an `object` codec, but that doesn't account for the arbitrary field name keys that can be provided. OpenAPI supports object types with "additional properties", but I don't know if we can declare a specific type for those properties. There might or might not be a reasonable path to extending Autodocodec to handle this case.
Ticket: [GDC-585](https://hasurahq.atlassian.net/browse/GDC-585)
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6978
GitOrigin-RevId: 0b0dcfd59ebd1d5022ff2ab86dd8d4c6f93bd039
Dependencies seem to get concatenated very often, so let's use a data structure that supports efficient concatenation.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7050
GitOrigin-RevId: 6331963f99f17d1b908a6038318d8c4834cf4dd7
