Antonio-RiveroMartnez commented on PR #27145:
URL: https://github.com/apache/superset/pull/27145#issuecomment-1956523201
> > > No offense taken, all input is welcome. Now, the use of `time_shift`
is for the prefixed options in the control, users can still use a `Custom`
range and use `DATEADD`, this control is just giving more `automatic` and
`prefixed` ranges to compare without the need to worrying about extra queries
setup.
> >
> >
> > The `time_shift` looks like redundant, it's too much specific use case.
>
> I could try using `dateadd`, however, for the `inherited` time ranges it
fell short, isn't it? But let me see what I can do in the backend to compute
them.
Using `DATEADD` when sending the queries doesn't work bacause it leads to
miscalculations of the datetime. For example:
**Time filter comparator**: `last year : today`
**Time offset**: 1 year
in order to send the query with `DATEADD` you would need something like
`DATEADD(DATETIME('last year'), -1, year)` and `DATEADD(DATETIME('ltoday'), -1,
year)`
However, the moment you use `DATETIME('last year')` it miscalculates the
datetime which gives you a different result from the original `last year`.
And trying to parse the possibles ways to still send the comparator with
`DATEADD` might lead to fall under the same mistake form before of duplicating
logic in the frontend.
This is driving the decision to instead compute the `DATEADD` function in
the backend using the value from the new control as reference and sending this
as a new optional field in the QueryObject.
With this approach we:
1. don't duplicate logic in frontend and we're in total control over when
the `DATEADD` is applied
2. Do not make use of legacy `time_shift`
3. We don't make use of `time_offsets` which again is tied to time grains, x
axis columns etc
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org
For additional commands, e-mail: notifications-h...@superset.apache.org
