Skip to content

Add support for DateTime filters in PostgreSQL - #3728

Merged
Arjun Narendra (ArjunNarendra) merged 14 commits into
Azure:mainfrom
ArjunNarendra:user/an/postgres-db-type-new
Jul 29, 2026
Merged

Add support for DateTime filters in PostgreSQL#3728
Arjun Narendra (ArjunNarendra) merged 14 commits into
Azure:mainfrom
ArjunNarendra:user/an/postgres-db-type-new

Conversation

@ArjunNarendra

@ArjunNarendra Arjun Narendra (ArjunNarendra) commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Why make this change?

This pull request is to address #3094, which is a bug that happens because certain date/time SQL parameters are not being parsed to their appropriate .NET type (DateTime or DateTimeOffset) and are instead being treated as raw text. This is leading to type conversion issues when executing the underlying SQL query.

What is this change?

I have provided an overridden implementation of MakeDbConnectionParam in BaseSqlQueryStructure.cs. This method does some extra pre-processing for PostgreSQL parameters specifically by parsing each parameter into its appropriate system type before calling the base class implementation of MakeDbConnectionParam in BaseQueryStructure.cs. The system type of each parameter is retrieved from metadata of the underlying column that this parameter corresponds to via the method GetColumnSystemType. This change fixes the relevant issue because now parameters which correspond to an underlying datetime column in the schema are cast to their appropriate .NET type instead of falling through as text before building the final SQL query. Furthermore, this change is limited in scope to apply this parameter casting only when the underlying database is PostgreSQL. This ensures we do not see unexpected behavior with other database types where this sort of parameter casting may be unnecessary and/or erroneous.

My original thought was to modify the method ExtractValueFromIValueNode in ExecutionHelper.cs to explicitly handle an IValueNode with a GraphQL scalar type of SupportedHotChocolateTypes.DATETIME_TYPE by parsing the IValueNode as a DateTime system type before being returned. For all practical purposes, this has the same desired effect as parsing the parameter in MakeDbConnectionParam, but the call to ExtractValueFromIValueNode happens upstream of the call to MakeDbConnectionParam.

I believe that casting the parameters to their appropriate .NET type in MakeDbConnectionParam is appropriate because the method literally builds each parameter for the SQL query and the .NET type casting can be considered a part of this parameter building process. I do not think .NET type casting is as appropriate in ExtractValueFromIValueNode because this method serves the broader purpose of extracting a value from a GraphQL IValueNode, where the IValueNode could contain a scalar but it could also contain a variable that needs to be resolved recursively. For parameters that need to be cast to a .NET type, the control flow will go from ExtractValueFromIValueNode to eventually MakeDbConnectionParam, but again, MakeDbConnectionParam serves the sole purpose of building the parameter while ExtractValueFromIValueNode serves a broader purpose.

How was this tested?

  • [ X] Integration Tests

Sample Request(s)

With query:

query {
  assignments(filter: { assignment_due_date: { gte: "2026-03-23T00:00:00.000Z" } }) {
    items {
      assignment_id
      assignment_name
      assignment_due_date
    }
  }
}

Before:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z'::text;

After:

SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z';

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aims to fix PostgreSQL GraphQL filter failures for date/time columns (issue #3094) by ensuring filter parameter values are converted from raw GraphQL string values into the appropriate .NET types (DateTime / DateTimeOffset) before being added as DB parameters, preventing PostgreSQL from treating them as text.

Changes:

  • Override BaseSqlQueryStructure.MakeDbConnectionParam to pre-parse PostgreSQL column parameters from string into the column’s inferred .NET system type before delegating to the base parameter creation logic.
  • Minor GraphQL schema-generation refactors/cleanups (including primary key directive usage changes and DocumentNode composition changes).
  • Improve/clarify several metadata-provider exception messages and update related comments/constants organization.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
src/Service.GraphQLBuilder/Sql/SchemaConverter.cs Adjusts schema generation docs and changes how the primaryKey directive is emitted for PK fields.
src/Service.GraphQLBuilder/GraphQLTypes/SupportedTypes.cs Reorganizes date/time-related type constants and updates comments.
src/Core/Services/MetadataProviders/SqlMetadataProvider.cs Improves exception messages and clarifies a schema-fill comment.
src/Core/Services/GraphQLSchemaCreator.cs Refactors schema assembly and uses WithDefinitions when composing root DocumentNode.
src/Core/Resolvers/Sql Query Structures/BaseSqlQueryStructure.cs Adds PostgreSQL-specific parameter type pre-processing in MakeDbConnectionParam to address date/time filter casting issues.

Comment thread src/Service.GraphQLBuilder/Sql/SchemaConverter.cs
Comment thread src/Core/Resolvers/Sql Query Structures/BaseSqlQueryStructure.cs
Comment thread src/Service.GraphQLBuilder/GraphQLTypes/SupportedTypes.cs Outdated
@unattendedfaxmachine

Copy link
Copy Markdown

Adding context that this PR continues the work initially started in #3250 and #3101

Comment thread src/Core/Services/MetadataProviders/SqlMetadataProvider.cs Outdated
Comment thread src/Core/Services/GraphQLSchemaCreator.cs

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good description on what is the change. Needs DateTime integration tests.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, assuming the comments would be addressed correctly.

Comment thread src/Core/Resolvers/Sql Query Structures/BaseSqlQueryStructure.cs Outdated
Comment thread src/Core/Services/GraphQLSchemaCreator.cs
Comment thread src/Service.GraphQLBuilder/GraphQLTypes/SupportedTypes.cs Outdated
@ArjunNarendra
Arjun Narendra (ArjunNarendra) merged commit eb3a58b into Azure:main Jul 29, 2026
14 checks passed
@ArjunNarendra
Arjun Narendra (ArjunNarendra) deleted the user/an/postgres-db-type-new branch July 29, 2026 05:54
naxing123 pushed a commit that referenced this pull request Aug 12, 2026
## Why make this change?

This pull request is to address
#3094, which is a bug
that happens because certain date/time SQL parameters are not being
parsed to their appropriate .NET type (`DateTime` or `DateTimeOffset`)
and are instead being treated as raw text. This is leading to type
conversion issues when executing the underlying SQL query.

## What is this change?

I have provided an overridden implementation of `MakeDbConnectionParam`
in `BaseSqlQueryStructure.cs`. This method does some extra
pre-processing for PostgreSQL parameters specifically by parsing each
parameter into its appropriate system type before calling the base class
implementation of `MakeDbConnectionParam` in `BaseQueryStructure.cs`.
The system type of each parameter is retrieved from metadata of the
underlying column that this parameter corresponds to via the method
`GetColumnSystemType`. This change fixes the relevant issue because now
parameters which correspond to an underlying `datetime` column in the
schema are cast to their appropriate .NET type instead of falling
through as text before building the final SQL query. Furthermore, this
change is limited in scope to apply this parameter casting only when the
underlying database is PostgreSQL. This ensures we do not see unexpected
behavior with other database types where this sort of parameter casting
may be unnecessary and/or erroneous.

My original thought was to modify the method
`ExtractValueFromIValueNode` in `ExecutionHelper.cs` to explicitly
handle an `IValueNode` with a GraphQL scalar type of
`SupportedHotChocolateTypes.DATETIME_TYPE` by parsing the `IValueNode`
as a `DateTime` system type before being returned. For all practical
purposes, this has the same desired effect as parsing the parameter in
`MakeDbConnectionParam`, but the call to `ExtractValueFromIValueNode`
happens upstream of the call to `MakeDbConnectionParam`.

I believe that casting the parameters to their appropriate .NET type in
`MakeDbConnectionParam` is appropriate because the method literally
builds each parameter for the SQL query and the .NET type casting can be
considered a part of this parameter building process. I do not think
.NET type casting is as appropriate in `ExtractValueFromIValueNode`
because this method serves the broader purpose of extracting a value
from a GraphQL `IValueNode`, where the `IValueNode` could contain a
scalar but it could also contain a variable that needs to be resolved
recursively. For parameters that need to be cast to a .NET type, the
control flow will go from `ExtractValueFromIValueNode` to eventually
`MakeDbConnectionParam`, but again, `MakeDbConnectionParam` serves the
sole purpose of building the parameter while
`ExtractValueFromIValueNode` serves a broader purpose.

## How was this tested?

- [ X] Integration Tests

## Sample Request(s)

With query:

```
query {
  assignments(filter: { assignment_due_date: { gte: "2026-03-23T00:00:00.000Z" } }) {
    items {
      assignment_id
      assignment_name
      assignment_due_date
    }
  }
}
```

Before:

```
SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z'::text;
```

After:

```
SELECT * FROM public."Assignments"
WHERE "Assignments"."assignment_due_date" >= '2026-03-23T00:00:00.000Z';
```

(cherry picked from commit eb3a58b)
naxing123 added a commit that referenced this pull request Aug 12, 2026
…ease/2.0 (#3767)

Ports the PostgreSQL GraphQL groupby/aggregation and related feature
commits from `main` (released in v2.1.0-rc) to `release/2.0` via
cherry-pick.

## Commits ported (chronological)
| PR | Title |
|----|-------|
| #3450 | Fix GraphQL aggregation features disabled when runtime.graphql
config section is absent |
| #3694 | Database policy support for PUT/PATCH operations - PostgreSQL
|
| #3728 | Add support for DateTime filters in PostgreSQL |
| #3750 | Fix column mapping in GroupBy and aggregation queries |
| #3741 | Add groupby/aggregation support for PostgreSQL in GraphQL |
| #3753 | Enhance test coverage for GraphQL queries by adding orderBy
clause |

## Notes
- All six cherry-picks applied cleanly.
- One manual adjustment in `SqlMutationEngine.cs` (part of #3694 port):
the original referenced `effectiveOperationType` (a local introduced by
the unrelated refactor #3287, which is not in `release/2.0`).
Substituted `context.OperationType`, which is functionally equivalent in
that non-upsert branch and matches the `release/2.0` convention. Folded
into the #3694 commit.
- Solution builds clean (0 warnings, 0 errors).
- Integration tests (PostgreSql/MsSql) require live databases and were
not run locally.

---------

Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Aniruddh25 <3513779+Aniruddh25@users.noreply.github.com>
Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
Co-authored-by: Souvik Ghosh <souvikofficial04@gmail.com>
Co-authored-by: Arjun Narendra <arjunnarendra1@gmail.com>
Co-authored-by: RubenCerna2079 <32799214+RubenCerna2079@users.noreply.github.com>
Co-authored-by: Arpit Gupta <106474712+ar-guptaar@users.noreply.github.com>
Co-authored-by: ARPIT GUPTA <guptaar@microsoft.com>
Co-authored-by: Anusha Kolan <anushakolan10@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants