Commit Graph

13 Commits

Author SHA1 Message Date
paritosh-08
5a598875bb update changelog for v2024.07.18 (#854)
<!-- The PR description should answer 2 (maybe 3) important questions:
-->

### What

update changelog for new release

### How

:)

V3_GIT_ORIGIN_REV_ID: 6620f9923f393d190f0f2fab1aced1cff4d6aec0
2024-07-18 13:55:28 +00:00
Rakesh Emmadi
561b908342 Implement remote relationship predicates in where filter clause (#761)
Now, users can filter their queries using remote relationships in the
filter predicate. Users need to provide the relationships for comparison
in `comparableRelationships` field of the newer `BooleanExpressionType`
opendd metadata.

Minimal Algorithm:
```
Relationship: ARemoteB => Model_A -> Model_B (remote NDC)
Column Mapping: (A_column_1, B_column_1), (A_column_2, B_column_2).

query:
  Model_A:
    where: ARemoteB: {B_column_3: {_eq: value}}

Step 1: Fetch RHS column values (in mapping) from remote target model
  SELECT B_column_1, B_column_2 from model_b_collection WHERE B_column_3 = value;
yields  the following rows
[
  [(B_column_1, b_value_1), (B_column_2, b_value_2)],
  [(B_column_1, b_value_11), (B_column_2, b_value_22)],
]

Step 2: Using above rows the generate LHS column filter for Model_A query.

SELECT <fields> from model_a_collection WHERE
  ((A_column_1 = b_value_1) AND (A_column_2 = b_value_2))
 OR ((A_column_1 = b_value_11) AND (A_column_2 = b_value_22))

The above comparison is equivalent to
WHERE
  (A_column_1, A_column_2) IN ((b_value_1, b_value_11), (b_value_2, b_value_22))

```

Sample query:
```graphql
query MyQuery {
 Track(
    where: {
      _or: [
        { AlbumRemote: { Artist: { ArtistId: { _eq: 2 } } } }
        { TrackId: { _eq: 3 } }
      ]
    }
  ) {
    TrackId
    AlbumRemote {
      Artist {
        ArtistId
        Name
      }
    }
  }
}
```
In the query above, `AlbumRemote` is a remote relationship which targets
a model backed by a different data connector.

V3_GIT_ORIGIN_REV_ID: 7aa76fcae83e1f22de460f1eef5648fb7a35c047
2024-07-18 07:47:04 +00:00
Daniel Chambers
455724dd07 Fixed command targeted relationships not using data connector argument names (#841)
### What
This PR fixes an issue where relationships that target commands do not
correctly use the data connector's argument name when making the ndc
request. Instead, they use the OpenDD argument name, which is incorrect.

For metadata where the OpenDD argument name is the same as the data
connector's argument name, the code works but only coincidentally.

### How
I've updated an existing test to change the name of the command argument
to be different from the data connector's argument name. This test
failed but is now fixed by this PR, which simply looks up the name of
the data connector argument name and uses that instead.

V3_GIT_ORIGIN_REV_ID: 71f1e812174c7bb9922792523129e4bcdce911ed
2024-07-17 08:37:18 +00:00
Daniel Harvey
d7ca64b497 Disallow filtering on nested array (#837)
<!-- The PR description should answer 2 (maybe 3) important questions:
-->

### What

Filtering on nested arrays doesn't work, let's make sure it's not
allowed for now.

<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->

<!-- Consider: do we need to add a changelog entry? -->

### How

Adding a check in `boolean_expression_types` stage.

<!-- How is it trying to accomplish it (what are the implementation
steps)? -->

---------

Co-authored-by: Gil Mizrahi <gil@gilmi.net>
V3_GIT_ORIGIN_REV_ID: cc08e8c24098c1fea9b6e1ee61b82ade989dd29a
2024-07-16 12:00:13 +00:00
Daniel Harvey
44b07f8055 release v2024.07.10 (#818)
<!-- The PR description should answer 2 (maybe 3) important questions:
-->

### What

Update changelogs for new release.

<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->

<!-- Consider: do we need to add a changelog entry? -->

### How

<!-- How is it trying to accomplish it (what are the implementation
steps)? -->

V3_GIT_ORIGIN_REV_ID: 7adfd3c2c53b912bb7c4604ebed93601a201c15e
2024-07-10 10:00:03 +00:00
paritosh-08
4b62f7decf release v2024.07.04 (#792)
Update the changelog for new version

---------

Co-authored-by: Anon Ray <ecthiender@users.noreply.github.com>
V3_GIT_ORIGIN_REV_ID: b87f16ebaa1471f010ec461be097bcfd6648c99a
2024-07-04 10:25:48 +00:00
Anon Ray
c1b9592f6b respect relationship comparison capability when generating relationship fields in model filter (#789)
### What

When generating GraphQL schema for relationship fields in model filter,
engine ignores `relation_comparisons` capability of the data connector.
Engine would generate schema for data connectors which don't have this
capability. This PR fixes that.

### How

While generating fields for the filter input type, take the relationship
capabilities into account.

The `ObjectBooleanExpressionType` and `BooleanExpressionType` objects
are quite different, hence their schema generation part is also
different, and is split in two different functions
(`build_comparable_relationships_schema`, and
`build_new_comparable_relationships_schema`). Added checking of
relationship comparison capability in both the functions.

V3_GIT_ORIGIN_REV_ID: dce2b88f7792e01e5bb390ecdb580e223ec80f01
2024-07-02 07:49:10 +00:00
Daniel Harvey
0123c558f1 Enable BooleanExpressionTypes (#783)
<!-- The PR description should answer 2 (maybe 3) important questions:
-->

### What

# BooleanExpressionType

A new metadata kind `BooleanExpressionType` can now be defined. These
can be used in place of `ObjectBooleanExpressionType` and
`DataConnectorScalarRepresentation`, and allow more granular control of
comparison operators and how they are used.

The old metadata types still work, but will eventually be deprecated.

```yaml
kind: BooleanExpressionType
version: v1
definition:
  name: album_bool_exp
  operand:
    object:
      type: Album
      comparableFields:
        - fieldName: AlbumId
          booleanExpressionType: pg_int_comparison_exp
        - fieldName: ArtistId
          booleanExpressionType: pg_int_comparison_exp_with_is_null
        - field: Address
          booleanExpressionType: address_bool_exp
      comparableRelationships:
        - relationshipName: Artist
          booleanExpressionType: artist_bool_exp
  logicalOperators:
    enable: true
  isNull:
    enable: true
  graphql:
    typeName: app_album_bool_exp
```

```yaml
kind: BooleanExpressionType
version: v1
definition:
  name: pg_int_comparison_exp
  operand:
    scalar:
      type: Int
      comparisonOperators:
        - name: equals
          argumentType: String!
        - name: _in
          argumentType: [String!]!
      dataConnectorOperatorMapping:
        - dataConnectorName: postgres_db
          dataConnectorScalarType: String
          operatorMapping:
            equals: _eq
  logicalOperators:
    enable: true
  isNull:
    enable: true
  graphql:
    typeName: app_postgres_int_bool_exp
```

<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->

<!-- Consider: do we need to add a changelog entry? -->

### How

Remove feature flag, unhide JsonSchema items, fix a few missing bits of
JsonSchema the tests didn't warn us about before.

<!-- How is it trying to accomplish it (what are the implementation
steps)? -->

V3_GIT_ORIGIN_REV_ID: dd3055d926fdeb7446cd57085679f2492a4358a1
2024-07-01 15:29:14 +00:00
Rakesh Emmadi
9e98ed2310 Implement query usage analytics (#713)
JIRA: https://hasurahq.atlassian.net/browse/V3ENGINE-176

This PR implements usage analytics
([RFC](https://docs.google.com/document/d/1k8_ZniiejxHhD0SphtEJ2mg6MoJON0dkk0q4b5WZWDE/edit))
for a GraphQL query when a request is made. The analytics data JSON is
attached to the span, whose details are provided below:
Span name - `execute`
Attribute - `internal.query_usage_analytics = <JSON-string>` OR
`internal.query_usage_analytics_error = <String>`

Refs:
- [Link](https://github.com/hasura/v3-engine/pull/606) to the PR, where
data types for usage analytics were added.
- [Link](https://github.com/hasura/v3-engine/pull/715) to the PR, where
some improvements are made to the analytics data types.

Note: Changelog entry is added.
V3_GIT_ORIGIN_REV_ID: f4089f3354b638533ff72fbec72951e883c31100
2024-07-01 12:10:12 +00:00
Philip Lykke Carlsen
25d4a3b5ea Add flag to toggle whether to expose internal errors (#759)
### What

This PR adds the ability to include internal errors in API responses via
a command line argument `--expose-internal-errors`.

The default behavior remains not to show the contents of internal error
messages.

V3_GIT_ORIGIN_REV_ID: 11c47286d3fbceeda71df3a224853633aeea8902
2024-06-27 12:43:23 +00:00
Daniel Chambers
5b2e36cd4f Fix NDC version used in JSON Schema references (#770)
This PR fixes the version of the NDC Spec that Open DD's JSON schema
references when it uses NDC's schema and capabilities types in the
`DataConnectorLink`. OpenDD references 0.1.4 of NDC, but uses 0.1.3 in
the JSON schema. This corrects that.

V3_GIT_ORIGIN_REV_ID: bdbb417b3227861dae7835f6d3bda0d1bf935ea7
2024-06-27 03:50:35 +00:00
Daniel Chambers
82c0c65bd0 Enable aggregate relationships by default (#765)
NOTE: This PR is stacked on #756 and should be shipped after that is
merged.

This PR enables the existing aggregate relationships work (see #725,
#731, #756) by default by removing the experimental flag it used to be
disabled behind.

The new OpenDD schema changes that were added are also unhidden so that
they are visible in the OpenDD JSON Schema.

V3_GIT_ORIGIN_REV_ID: cfd86d8a9ea61887ccf0f1a5d08bdcc3dda59cdc
2024-06-26 10:49:10 +00:00
Philip Lykke Carlsen
b5cf229dad Introduce a changelog file (#749)
## What

This PR introduces a changelog file, `changelog.md`.
Any PR that is not simply a technical refactor should include a relevant
entry in this file.

Additionally we also simplify the pull request template. The template
used to contain a section for a changelog entry, which is now rendered
irrelevant.

V3_GIT_ORIGIN_REV_ID: 00881d86ffe87c4c0584b88b960837543dde34b7
2024-06-25 09:00:44 +00:00