-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for range types #1079
Comments
@benbro They aren't explicitly supported so you won't be able to use operators specific to such columns, but everything else should work as expected, i.e, you can select and insert data. |
I won't be able to use Range Functions and Operators? |
Currently no. We'll add support soon. |
You can follow the progress here: #1082 |
Thanks |
Current usability workarounds?
https://github.com/WhoopInc/node-pg-range
Range objectspg-range uses stRange.js, a JavaScript range library, to provide a Values of (PostgreSQL) type
will be automatically parsed into instances of Warning: When constructing range objects for use in queries, use the |
…graphql use but GraphqlConfig is missing aggregates configuration (#1079) ### What If a user configures `AggregateExpressions` in their metadata with the `graphql` section configured, but forgets to configure `aggregates` in `GraphqlConfig`, an error was raised and the build failed. This scenario occurs when a user has an existing pre-aggregrates metadata and are adding aggregates to it later. While simply adding the required configuration to `GraphqlConfig` would fix the error, there are cases where the `GraphqlConfig` is not in the user's current repo, such as where they are working in a separate subgraph repo and the `GraphqlConfig` is managed elsewhere and requires a coordinated change. This PR turns that error into a warning and allows a successful build. The build will not have aggregates show up in the GraphQL, but does succeed, which allows the user to progress until the `GraphqlConfig` is updated separately. ### How A new `AggregateExpressionIssue` type is added and the error is moved from `AggregateExpressionError` to that type instead. The code then logs the new issue and contributes it to the main issues collection. The test that checked for this error (a failure test) has been moved to a successful test and the warning can be seen at the bottom of the new snapshot file. V3_GIT_ORIGIN_REV_ID: 751590c484feec4ae03f079ae6a1bc0bf867ff64
…e is missing from GraphQlConfig (#1105) ### What This PR is similar to #1079 in that it relaxes a build error that occurs into a warning. If you define a `Model` with aggregates but you haven't defined the `query.aggregate` section in your `GraphqlConfig`, then you currently get a build error telling you to do it. This PR relaxes this to a warning and aggregates are just omitted from the Model GraphQL API schema. ### How The error is converted to an issue in metadata resolve. An existing test that tested that error has been shifted to a passing test and the new raised issue can be seen at the bottom of the resolved metadata snapshot. V3_GIT_ORIGIN_REV_ID: b864be90141e2a8940fa9a6269beb24021880636
Is it possible to support PostgreSQL range types?
They are not listed here.
The text was updated successfully, but these errors were encountered: