Graphback: Mongo queryBuilder not playing well with collection having a custom createdAt and updatedAt field.

Created on 29 Jun 2020  路  12Comments  路  Source: aerogear/graphback

The queryBuilder.ts tries to coerce custom createdAt field to a timestamp even when not using the datasync plugin.

I can have a collection with a custom createdAt and updatedAt of type DateTime as in https://github.com/aerogear/OpenVolunteerPlatform/blob/e604010b09aadbac59a2099b32e7eef183af11c3/platform/server/model/main.graphql#L82 (it is a _createdAt and not createdAt to work around this issue)

we have this logic that tries to coerce filtering values we have for these fields to timestamps - https://github.com/aerogear/graphback/blob/master/packages/graphback-runtime-mongodb/src/queryBuilder.ts#L88

which does not play well with a graphql query like https://github.com/aerogear/OpenVolunteerPlatform/blob/e604010b09aadbac59a2099b32e7eef183af11c3/platform/client-admin/src/graphql/queries/getTodayActionReport.graphql#L90

Since the value sent e.g 2020-06-29T22:00:00.000Z is not a number.

/cc @ssd71

bug triage

Most helpful comment

Ah.. ok.. that is bug then. My bad sorry!

All 12 comments

/cc @craicoverflow @wtrocki

Also cc @ssd71

@machi1990 could you help me reproduce this issue?

@machi1990 could you help me reproduce this issue?

Okay, I am setting up a minimal reproducer for you.

issue-1603.zip

@ssd71 Once you unzip the file, follow the instructions in the Readme.

Thank you so much! Sorry I misunderstood, I initially thought that you were having problems with using _createdAt, but I understand now,

This is kinda on me, I didn't check if we have some annotation before coercing these specific fields to timestamps, looking into this now

Using _createdAt instead is an awkward but doable workaround for now like you suggested

Thank you so much! Sorry I misunderstood, I initially thought that you were having problems with using _createdAt, but I understand now,

I was having problem when using createdAt so changing the field to _createdAt is the workaround.

This is kinda on me, I didn't check if we have some annotation before coercing these specific fields to timestamps, looking into this now

Using _createdAt instead is an awkward but doable workaround for now like you suggested

Yeap. I wanted to get stuffs running so... ;-)

Like this is price that we pay for lack of logging and error handling. I think we need to throw error when someone tries to have createdAt field on model that have it already. Also -1 for instant resolution, we haven't triaged this and we probably going to invalidate this approach anyway considering our discussion on updatedAt field and datasync

@wtrocki you are right about throwing error, but this problem is present even without using @versioned or @datasync so somebody who wants to handle createdAt on their own(without using our stuff) cannot do it because of this, tbh I'm not sure what would be best to do here

Can you explain how this happened without us adding this field using @versioned or @datasync.
it is not clear to me

@wtrocki
https://github.com/aerogear/graphback/blob/bb449d2391fc75ef2a40bdfb93819552ed82e053/packages/graphback-runtime-mongodb/src/queryBuilder.ts#L156
This code runs regardless of whether we have @versioned or @datasync, hence the issue

Ah.. ok.. that is bug then. My bad sorry!

Was this page helpful?
0 / 5 - 0 ratings