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

[sql-lab] unserializable object pandas.tslib.Timedelta #2322

Closed
2 of 3 tasks
rumbin opened this issue Mar 2, 2017 · 9 comments · Fixed by #3444
Closed
2 of 3 tasks

[sql-lab] unserializable object pandas.tslib.Timedelta #2322

rumbin opened this issue Mar 2, 2017 · 9 comments · Fixed by #3444

Comments

@rumbin
Copy link
Contributor

rumbin commented Mar 2, 2017

Make sure these boxes are checked before submitting your issue - thank you!

  • I have checked the superset logs for python stacktraces and included it here as text if any
  • I have reproduced the issue with at least the latest released version of superset
  • I have checked the issue tracker for the same issue and I haven't found one similar

May be related to #1900?

Superset version

0.15.4, 0.17.0, 0.17.4, 0.18.4, 0.18.5, 0.19.0, 0.19.1

Expected results

Calculating differences of two timestamps (on a postgres DB) yields a column of type interval.

Actual results

The (async) query in SQLLab seems to run endlessly. The stack trace of superset worker says TypeError: Unserializable object 1 days 00:00:00 of type <class 'pandas.tslib.Timedelta'>

Steps to reproduce

Run
select '2017-01-02'::timestamp - '2017--01-01'::timestamp as t_diff in SQLLab.

@rumbin rumbin changed the title SQLLab: unserializable object pandas.tslib.Timedelta [sql-lab] unserializable object pandas.tslib.Timedelta Mar 2, 2017
@xrmx
Copy link
Contributor

xrmx commented Mar 2, 2017

Please post the full backtrace, then please try yo upgrade pandas to the latest release and report back.

@rumbin
Copy link
Contributor Author

rumbin commented Mar 7, 2017

Here is the full backtrace with pandas==0.19.2:

[2017-03-07 12:45:21,790: INFO/MainProcess] Received task: superset.sql_lab.get_sql_results[881d070f-f286-4f8d-b25f-ce6f450a8df1]
[2017-03-07 12:45:21,879: INFO/Worker-23] Running query:
select '2017-01-02'::timestamp - '2017--01-01'::timestamp as t_diff
[2017-03-07 12:45:21,911: ERROR/MainProcess] Task superset.sql_lab.get_sql_results[881d070f-f286-4f8d-b25f-ce6f450a8df1] raised unexpected: TypeError("Unserializable object 1 days 00:00:00 of type <class 'pandas.tslib.Timedelta'>",)
Traceback (most recent call last):
  File "/opt/apps/superset/venv_py3_superset/lib/python3.4/site-packages/celery/app/trace.py", line 240, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/opt/apps/superset/venv_py3_superset/lib/python3.4/site-packages/celery/app/trace.py", line 438, in __protected_call__
    return self.run(*args, **kwargs)
  File "/opt/apps/superset/venv_py3_superset/lib/python3.4/site-packages/superset/sql_lab.py", line 152, in get_sql_results
    payload = json.dumps(payload, default=utils.json_iso_dttm_ser)
  File "/usr/lib64/python3.4/json/__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "/usr/lib64/python3.4/json/encoder.py", line 192, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib64/python3.4/json/encoder.py", line 250, in iterencode
    return _iterencode(o, 0)
  File "/opt/apps/superset/venv_py3_superset/lib/python3.4/site-packages/superset/utils.py", line 275, in json_iso_dttm_ser
    "Unserializable object {} of type {}".format(obj, type(obj))
TypeError: Unserializable object 1 days 00:00:00 of type <class 'pandas.tslib.Timedelta'>

@rumbin rumbin closed this as completed Mar 7, 2017
@xrmx xrmx reopened this Mar 7, 2017
@rumbin
Copy link
Contributor Author

rumbin commented Mar 7, 2017

@xrmx: Picked wrong button… Thanks for reopening!

@rumbin
Copy link
Contributor Author

rumbin commented Mar 9, 2017

The bug still exists in superset 0.17.0; adding this information to the initial report.

@rumbin
Copy link
Contributor Author

rumbin commented Apr 12, 2017

Still present in 0.17.4.

Can anyone else confirm this bug, please, or maybe test whether this is related to the type of database that is being queried?

@Marigold
Copy link
Contributor

I believe it's related to this issue #1929. I'm getting this error too with PostgreSQL when using TIMESTAMP WITH TIME ZONE column.

@rumbin
Copy link
Contributor Author

rumbin commented Jul 17, 2017

Still present in 0.18.5

@manokhina
Copy link

Still present in 0.18.4 (obviously)

@rumbin
Copy link
Contributor Author

rumbin commented Sep 11, 2017

Still present in 0.19.1, unfortunately

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 a pull request may close this issue.

5 participants