-
Notifications
You must be signed in to change notification settings - Fork 1
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
Superset | filter by last * results in wrong timestamp. #96
Comments
Thanks for reporting. It would be interesting if this can also be reproduced on behalf of the SQLAlchemy dialect in crate-python, where a corresponding flaw would "just need a fix", when applicable. |
Created the table: CREATE TABLE IF NOT EXISTS "doc"."power_consumption" (
"ts" TIMESTAMP WITH TIME ZONE,
"global_active_power" REAL
); Inserted dummy rows using cr8 cr8 insert-fake-data --hosts https://USER:[email protected]:4200 --table "doc.power_consumption" --num-records 10000 |
Not sure if this is what you mean, but if I try the following the Base = declarative_base()
class Table1(Base):
__tablename__ = 'table1'
_id = sa.Column(sa.String, primary_key=True)
field1 = Column(String)
ts1 = Column(DateTime)
session=sessionmaker(bind=sa.create_engine("crate://localhost:4200", echo=True))()
Query=session.query(Table1.field1).filter(Table1.ts1 > datetime.datetime.now())
print (Query.statement.compile(dialect=session.bind.dialect, compile_kwargs={"literal_binds": True})) |
Yeah something like that, we wanted to evaluate. However, we haven't exactly checked how query generation works in Superset, specifically on the spot in question.
Would it actually be correct in case of CrateDB? So, no bug in the dialect per se, because it does not matter if we send it over as a string or a number? |
This issue has been addressed with apache/superset#27567 |
Thanks a stack! |
The issue is that when creating a chart in SuperSet using a filter (simple) on timestamp (ts) with either range (day/week/month) results in a query like this:
Instead of
The timestamp used has an extra (.0), which results in a timestamp in 56068 BC.
The text was updated successfully, but these errors were encountered: