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

feat: use strict ISO8601 datetime format in postgres engine spec #7057

Closed
wants to merge 1 commit into from
Closed

feat: use strict ISO8601 datetime format in postgres engine spec #7057

wants to merge 1 commit into from

Conversation

kovrus
Copy link

@kovrus kovrus commented Mar 19, 2019

The PostgresEngineSpec have the default implementation of the convert_dttm method that follows the %Y-%m-%d %H:%M:%S date time format. Despite the fact that the particular format is supported by PostgreSQL, it is not ISO8601 compliant, see section 4.3.2. The standard permits to omit the time designator T, but does not imply permission to replace it with a whitespace.

Therefore, it would be harder to use Superset with databases that support the PostgreSQL Wire Protocol and strictly follow ISO8601. This PR improves Superset integration with such databases.

@codecov-io
Copy link

codecov-io commented Mar 19, 2019

Codecov Report

Merging #7057 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #7057      +/-   ##
==========================================
- Coverage   64.46%   64.46%   -0.01%     
==========================================
  Files         421      421              
  Lines       20537    20539       +2     
  Branches     2247     2247              
==========================================
+ Hits        13240    13241       +1     
- Misses       7170     7171       +1     
  Partials      127      127
Impacted Files Coverage Δ
superset/db_engine_specs.py 56.87% <100%> (-0.02%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7ffdd6...31c0fa9. Read the comment docs.

@kristw kristw changed the title Use strict ISO8601 datetime format in postgres engine spec feat: use strict ISO8601 datetime format in postgres engine spec Mar 19, 2019
@kristw kristw added the enhancement:request Enhancement request submitted by anyone from the community label Mar 19, 2019
@@ -535,6 +535,10 @@ def get_timestamp_column(expression, column_name):
return f'"{column_name}"'
return column_name

@classmethod
def convert_dttm(cls, target_type, dttm):
return "'{}'".format(dttm.strftime('%Y-%m-%dT%H:%M:%S'))
Copy link
Member

Choose a reason for hiding this comment

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

wait isn't that identical to the parent's class method?

Copy link
Author

Choose a reason for hiding this comment

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

No, this one has the time designator, the parent's class method has whitespace instead. Please see a bit more detailed explanation in the PR description.

Copy link
Member

Choose a reason for hiding this comment

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

Oh sorry I missed that. Any idea as to whether this may be needed at the PostgresBaseEngineSpec level? (would also affect Snowflake, Vertica, Redshift)

Copy link
Author

Choose a reason for hiding this comment

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

I'd keep it simple in this PR. It really depends on the way they handle timestamps date/time types. Unfortunately, I am not familiar with either of those databases.

@kovrus
Copy link
Author

kovrus commented Apr 25, 2019

Closing it %Y-%m-%d %H:%M:%S is a valid SQL timestamp format.

@kovrus kovrus closed this Apr 25, 2019
@kovrus kovrus deleted the r/postgres-iso8601 branch April 25, 2019 20:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement:request Enhancement request submitted by anyone from the community
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants