-
-
Notifications
You must be signed in to change notification settings - Fork 22
Date handling for GQL #6
Comments
Just want to say I would love to see this feature coming :) (Thx for you good work at Ghost and for spotting issues even before users run across them!) |
I implemented this here: laran@279f363 I called them 'transformers'. Basically callbacks which transform each value. It's an extension of the work in #17. If that PR gets accepted the transformers can be merged in as well. |
@ErisDS Do you want to keep this issue? Let me know, then i will move it over to NQL 🙂 |
We can close this. It turns out dates do basically work and we use them in Ghost. If we decide to improve this, we can always raise a new issue with a proper spec for what we want to improve. |
At the moment, there is little-to-no consideration for date handling in GQL. There are a few mentions of dates in TryGhost/Ghost#5604. In particular the post-processing section under Implementation talks about handling dates after the parser is finished.
Date-like values can realistically appear in different forms:
It is very difficult to distinguish a date from another value at the lexer level, or to determine whether a String was intended to be a date or a string. The best way we have, therefore, to detect dates, is to assume that any value provided for a date-based property is a date.
That is, if the property name is
created_at
,updated_at
,published_at
,last_login
or any other known dates and the value is a Number, a Literal or a String, we should try to turn the value into a date usingnew Date()
. This provides us with a well understood set of recognised date formats, and should mean that passing dates from handlebars inside a Ghost theme will work.E.g.
{{#get "posts" filter="published_at: >'{{post.published_at}}'"}}
(note the date is wrapped in single-quotes), without any date handling, will create a query in the form:select * from "posts" where "posts"."published_at" > 'Sat Jun 27 2015 13:02:12 GMT+0100 (BST)'
And SQL doesn't know what to do with that date.
Instead we need to ensure that if we have a date that can be understood by
new Date
, then SQL is always passed a date in a format it understands.We also need to ensure this works for all the supported SQL types: SQLite, MySQL and pg.
The text was updated successfully, but these errors were encountered: