## Description
As identified in hasura/graphql-engine#8096, the format string we used for timestamps was incorrect; we were using `%F`, which expands to `%Y-%m-%d`; but that meant that the year was not padded to four digits: `0001` would be represented simply as `1`. However, Postgres inteprets that `1` as `2001`, probably due to interpretation rules about two-digit years (in `25/12/01`, `01` is indeed `2001`).
```
# create table timestamp_test ( test timestamptz );
CREATE TABLE
# insert into timestamp_test values ('1-01-01T00:00:57Z');
INSERT 0 1
# select * from timestamp_test;
test
------------------------
2001-01-01 00:00:57+00
(1 row)
```
To fix this, this PR changes the format string to use `%0Y`, which always pads the year number with zeroes.
## Remaining work
- [x] write Changelog entry
- [ ] copy timestamp tests from the python suite into the hspec tests
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/3536
GitOrigin-RevId: fa144111358339fd4a35b32d888c1d2c5b418ea6
>
## Description ✍️
->
Tracked in https://github.com/hasura/lux/pull/3904
Part of https://github.com/hasura/lux/issues/4136
## Changelog ✍️
- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR.
If no changelog is required, then add the `no-changelog-required` label.
## Affected components ✍️
- [x] Docs
### Metadata ✍
Does this PR add a new Metadata feature?
- ❎ No
### GraphQL ✍
- ✅ No new GraphQL schema is generated
### Breaking changes ✍
- ✅ No Breaking changes
### Kodiak commit message
#### Commit title
[docs] Add another FAQ to the project hibernation page
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4447
GitOrigin-RevId: 9e2681c12bdac69f992419a181503ef44672d55b
…p CI (#3975)
Trying out a new convention here for jobs that generate multiple
artifacts at different points in time, and where downstream jobs depend
on just a particular subset of artifacts and don't need to wait for the
entire job. We accomplish this with separate `Input` steps, which we
unblock manually via calls to the buildkite API once particular sets of
artifacts are complete.
We could accomplish the same thing by having multiple build server jobs
focused on particular targets ( this is in fact how it used to work)
but that is quite wasteful of CI resources; in order to build any of
the binaries quickly, we need significant number of cores; but if we
only build particular targets, we don't take advantage I've all those
cores relative to the parallelism a full cabal build gives us. That
would likely be more difficult to maintain as well.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4256
Co-authored-by: Vishnu Bharathi <4211715+scriptnull@users.noreply.github.com>
GitOrigin-RevId: 5f5603da8a85f9a491877d51a7c08764c7199602
### Description
As part of the cache building process, we create / update / migrate the catalog that each DB uses as a place to store event trigger information. The function that decides how this should be done was doing an explicit `case ... of` on the backend tag, instead of delegating to one of the backend classes. The downsides of this is that:
- it adds a "friction point" where the backend matters in the core of the engine, which is otherwise written to be almost entirely backend-agnostic
- it creates imports from deep in the engine to the `Backends`, which we try to restrict to a very small set of clearly identified files (the `Instances` files)
- it is currently implemented using a "catch all" default case, which might not always be correct for new backends
This PR makes the catalog updating process a part of `BackendMetadata`, and cleans the corresponding schema cache code.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4457
GitOrigin-RevId: 592f0eaa97a7c38f4e6d4400e1d2353aab12c97e
>
## Description ✍️
->
Tracked in https://github.com/hasura/lux/pull/3904
Part of https://github.com/hasura/lux/issues/4136
## Changelog ✍️
- [x] `CHANGELOG.md` is updated with user-facing content relevant to this PR.
If no changelog is required, then add the `no-changelog-required` label.
## Affected components ✍️
- [x] Docs
### Metadata ✍
Does this PR add a new Metadata feature?
- ❎ No
### GraphQL ✍
- ✅ No new GraphQL schema is generated
### Breaking changes ✍
- ✅ No Breaking changes
### Kodiak commit message
#### Commit title
[docs] Document the suspension of free projects that are unused
#### Commit body
Unused free projects are suspended given two previous notices to the owner. A project becomes inactive when it's unused for 3 months.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4389
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
GitOrigin-RevId: e4daed2bba6fe5d965c64c00f2aa4104afe593e7
## Description
As the name suggests, `DML.Internal` contains internal implementation details of RQL's DML. However, a lot of unrelated parts of the codebase still use some of the code it contains. This PR fixes this, and removes all imports of `RQL.DML.Internal` from outside of `RQL.DML`. Most of the time, this involves moving a function out of `DML.Internal` to an underlying module (see `getRolePermInfo`) or moving a function _back_ into it (see `checkRetCols`).
This PR also clarifies a bit the situation with `withTyAnn` and `withTypeAnn` by renaming the former into `withScalarTypeAnn` and moving them together. Worth noting: there might be a bug lurking in that function, as it doesn't seem to use the proper type annotations for some extension types!
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/4380
GitOrigin-RevId: c8ae5b4e8378fefc0bcccf778d97813df727d3cb
