Skip to content
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

Feature/Issue: AWSDate Type Serialization Issue with Override Decorator #165

Closed
d-e-a-n-f opened this issue Sep 8, 2023 · 3 comments
Closed

Comments

@d-e-a-n-f
Copy link

Description:

When using the AWSDate type inside the override decorator /// @gql(scalars: { asOfDate: "AWSDate" }), the package struggles with correctly serializing from an ISO8601 DateTime to a Date.

Expected Behavior:

  1. When the AWSDate type is employed, I anticipate an automatic conversion that adapts the Date object (as given by Prisma) into an appropriate format compatible with AWSDate.
  2. The filter functionality for this field should mirror the behavior observed with DateTime. Currently, it defaults to a StringFilter, which is inconsistent with expected behavior.

Schema Model Field:

asOfDate              DateTime          @db.Date @map("as_of_date")

Relevant Screenshot:
AWSDate Serialization Issue

@maoosi
Copy link
Owner

maoosi commented Sep 9, 2023

The date format issue you're facing is due to Prisma Client. It always returns dates as DateTime, regardless of the database format used. Here are some open issues about it:

prisma/prisma#7490
prisma/prisma#4355

Prisma-AppSync only acts as a bridge that connects Prisma to AWS AppSync and doesn't alter the data. Supporting AWSDate like AWSDateTime can only happen after the Prisma team fixes this issue.

For your use case, I would suggest removing /// @gql(scalars: { asOfDate: "AWSDate" }) entirely, so the generated GraphQL field will fallback to AWSDateTime (similar format to Prisma Client). Even though the format returned will be a DateTime, it should still save as Date in your Database.

@d-e-a-n-f
Copy link
Author

Hi @maoosi , Thanks for the response on this! I am aware of the Prisma issue which I dont think they will ever fix so thought it could be handled in this package potentially.

Although, I agree it is not an issue with this package!

We have a solution for this using the prisma middleware or extensions, is there anyway of overriding the prisma client in prisma-appsync that would allow us to carry over our extensions?

@maoosi
Copy link
Owner

maoosi commented Sep 11, 2023

@d-e-a-n-f yes, absolutely! You can access the underlying Prisma Client instance like this:

// init prisma-appsync
const prismaAppSync = new PrismaAppSync()

// middleware
prismaAppSync.prismaClient.$use(async (params, next) => {
    return next(params)
})

// lambda resolver
export const main = async (event: AppSyncResolverEvent<any>) => {
    return await prismaAppSync.resolve({ event })
}

@maoosi maoosi closed this as completed Sep 11, 2023
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

No branches or pull requests

2 participants