>
### Description
We want to hide postgres system schemas like `pg_toast` and `pg_temp` and their variations (ex. `pg_toast_temp_35`) from showing up in console.
>
### 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] Console
### Related Issues
->
https://github.com/hasura/graphql-engine/issues/6954
### Solution and Design
>
We can achieve this by updating the `schemaListSql` query for postgres datasources to filter out postgres system schemas.
### Steps to test and verify
>
1. Add a postgres datasource containing some system schemas
2. The system schemas should not show up in console
https://github.com/hasura/graphql-engine-mono/pull/1499
Co-authored-by: Aleksandra Sikora <9019397+beerose@users.noreply.github.com>
GitOrigin-RevId: 6a179b9d5cd4d061ae9fda17bf3824321cf7e96e
A pull request for cleaning up small issues, bugs, redundancies and missing things in the BigQuery backend.
Summary:
1. Remove duplicate projection fields - BigQuery rejects these.
2. Add order_by to the test suite cases, as it was returning inconsistent results.
3. Add lots of in FromIr about how the dataloader approach is given support.
4. Produce the correct output structure for aggregates:
a. Should be a singleton object for a top-level aggregate query.
b. Should have appropriate aggregate{} and nodes{} labels.
c. **Support for nodes** (via array_agg).
5. Smooth over support of array aggregates by removing the fields used for joining with an explicit projection of each wanted field.
https://github.com/hasura/graphql-engine-mono/pull/1317
Co-authored-by: Vamshi Surabhi <6562944+0x777@users.noreply.github.com>
GitOrigin-RevId: cd3899f4667770a27055f94988ef2a6d5808f1f5
Remote relationships are now supported on SQL Server and BigQuery. The major change though is the re-architecture of remote join execution logic. Prior to this PR, each backend is responsible for processing the remote relationships that are part of their AST.
This is not ideal as there is nothing specific about a remote join's execution that ties it to a backend. The only backend specific part is whether or not the specification of the remote relationship is valid (i.e, we'll need to validate whether the scalars are compatible).
The approach now changes to this:
1. Before delegating the AST to the backend, we traverse the AST, collect all the remote joins while modifying the AST to add necessary join fields where needed.
1. Once the remote joins are collected from the AST, the database call is made to fetch the response. The necessary data for the remote join(s) is collected from the database's response and one or more remote schema calls are constructed as necessary.
1. The remote schema calls are then executed and the data from the database and from the remote schemas is joined to produce the final response.
### Known issues
1. Ideally the traversal of the IR to collect remote joins should return an AST which does not include remote join fields. This operation can be type safe but isn't taken up as part of the PR.
1. There is a lot of code duplication between `Transport/HTTP.hs` and `Transport/Websocket.hs` which needs to be fixed ASAP. This too hasn't been taken up by this PR.
1. The type which represents the execution plan is only modified to handle our current remote joins and as such it will have to be changed to accommodate general remote joins.
1. Use of lenses would have reduced the boilerplate code to collect remote joins from the base AST.
1. The current remote join logic assumes that the join columns of a remote relationship appear with their names in the database response. This however is incorrect as they could be aliased. This can be taken up by anyone, I've left a comment in the code.
### Notes to the reviewers
I think it is best reviewed commit by commit.
1. The first one is very straight forward.
1. The second one refactors the remote join execution logic but other than moving things around, it doesn't change the user facing functionality. This moves Postgres specific parts to `Backends/Postgres` module from `Execute`. Some IR related code to `Hasura.RQL.IR` module. Simplifies various type class function signatures as a backend doesn't have to handle remote joins anymore
1. The third one fixes partial case matches that for some weird reason weren't shown as warnings before this refactor
1. The fourth one generalizes the validation logic of remote relationships and implements `scalarTypeGraphQLName` function on SQL Server and BigQuery which is used by the validation logic. This enables remote relationships on BigQuery and SQL Server.
https://github.com/hasura/graphql-engine-mono/pull/1497
GitOrigin-RevId: 77dd8eed326602b16e9a8496f52f46d22b795598
This reverts the remote schema type customisation and namespacing feature temporarily as we test for certain conditions.
GitOrigin-RevId: f8ee97233da4597f703970c3998664c03582d8e7
Modify page for mssql.
Column edit, add and delete
Pk add and delete
unique key add and delete
> Known Issues
> It is not because of this PR, but evident after implementing this changes.
> Table comments section is not only showing table comments but also anything that has `SYS.EXTENDED_PROPERTIES` with the table id, we may need to fix this by adding more conditions while fetching the table comments
> issue: https://github.com/hasura/graphql-engine-mono/issues/1486
Update
> Found a common issue while testing this PR, and it happens for PG tables too, so keeping it as a different issue
https://github.com/hasura/graphql-engine/issues/7018
GitOrigin-RevId: f7883a797ce8d25034824ae35668b1f830e59c70
>
### Description
>
### 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] Server
### Related Issues
->
Fixes#1528
### Solution and Design
>
Only replace connection configuration instead of replacing entire metadata with empty one.
GitOrigin-RevId: f9a16dcc7b1219ec1af915bf083622fcb7dde69a
Closes: https://github.com/hasura/graphql-engine/issues/6858
Description:
Following two things are done:
1. Show compatible functions in the Untracked custom functions list (i.e. even those with ROWTYPE arg)
2. When a function with ROWTYPE argument is tracked, a confirmatory dialogue box is shown. The text reads `This function can be added as a root field or a computed field inside a table` and the buttons reflect the options: `Add as root field`, `Add as computed field` (this will take the user to the Modify -> Add a computed field section of the first-row type argument)
Affected Component:
- [x] Console
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
Co-authored-by: Abhijeet Khangarot <26903230+abhi40308@users.noreply.github.com>
GitOrigin-RevId: 089944aadba73f7a77e220a49489846ff1cb9540
adds foreign key functionality to mssql tables under Modify Tab.
Steps to test:
1. Connect an MSSQL data source.
2. Create a table
3. go to modify page
4. make sure the `Add foreign key `button is visible
5. click on `Add foreign key`, and try to add FK
6. after adding the FK, we will see the `edit` and `remove` button, try to edit and remove the FK
Co-authored-by: Vijay Prasanna <11921040+vijayprasanna13@users.noreply.github.com>
GitOrigin-RevId: 63be7c4ef909503ac05096a64c686b72f7c47307
Before: on edit source page, changing data source name was not allowed and the input disabled.
Now: data source name can be changed on edit source page.
Note:
- ~When only the data source name is changed, a request is sent for renaming and another for updating data source even when other values of the data source configuration weren't changed.~
- This has been fixed and should be tested thus:
- run `npm run jest`
- on edit source UI, change only data source name and confirm that only `rename_source` request is being sent through network tab in dev tools
- change any other fields but the source name, and confirm that only `add_source` with `replace_configuration: true` is sent.
- change both source name and any other field in the form and confirm that both request are sent (in this order: rename request before add request) and export_metadata request only sent once after that.
- Try with bigquery, mssql and postgres
Possible Refactor:
- consider if `renameDataSource` and `addDataSource`, can be refactored or left as is
Co-authored-by: Aleksandra Sikora <9019397+beerose@users.noreply.github.com>
GitOrigin-RevId: cbb041ac8362fd94de5aa19bfa61c0cde8703459
### Description
This PR adds `Create Table` view for MSSQL server schemas.
### Changelist
* [x] Add basic `create table` form view on navigating from Schema's create table action.
* [x] Hide frequently selected columns button.
* [x] Allow the user to manually add column types for now: convert `select` for columns to a `text` input .
* [x] Remove `Restrict` radio selection for foreign key constraints.
* [x] Add SQL query for Create table in MSSQL.
### Screenshot
### 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.
### Modified components
- Console
Co-authored-by: Aleksandra Sikora <9019397+beerose@users.noreply.github.com>
GitOrigin-RevId: a783b5940198ecf582d1cd6ad4d4224efabf59fc
event catalog:
- `hdb_catalog` is no longer automatically created
- catalog is initialised when the first event trigger is created
- catalog initialisation is done during the schema cache build, using `ArrowCache` so it is only run in response to a change to the set of event triggers
event queue:
- `processEventQueue` thread is prevented from starting when `HASURA_GRAPHQL_EVENTS_FETCH_INTERVAL=0`
- `processEventQueue` thread only processes sources for which at least one event trigger exists in some table in the source
Co-authored-by: Anon Ray <616387+ecthiender@users.noreply.github.com>
GitOrigin-RevId: 73f256465d62490cd2b59dcd074718679993d4fe
It contains 2 flags
all - To delete all migrations locally and on database
version - To delete a single migration locally and on database
Usage :
`hasura migrate delete --all`
`hasura migrate delete --version <version_number>`
Additional fix :
The `migrate squash` will deletes the migration history on server after squashing if user opts to delete the migrations.
closes https://github.com/hasura/graphql-engine-mono/issues/292
closes https://github.com/hasura/graphql-engine/issues/5373
closes https://github.com/hasura/graphql-engine/issues/6434
Co-authored-by: Aravind K P <8335904+scriptonist@users.noreply.github.com>
GitOrigin-RevId: fa7ceae7a1970d6724fb601a147900e880ad2e6f
