> 3) Ease the management overhead via upgrade story and layered
configuration. Maybe even with unified failure management.
I'm not sure I get how this is supposed to work. Can you go a bit more in
the details?
On Thu, Dec 9, 2021 at 3:39 PM Timo Walther wrote:
> Hi everyone,
>
> thanks for
Hi everyone,
thanks for the healthy discussion. Let us find a compromise to make all
parties happy.
> NULL in SQL essentially means "UNKNOWN"
This argument is true, but as a user I would like to know the `Why?` a
value is UNKNOWN. I could imagine users have spent hours on finding the
root
FYI: Opened https://github.com/apache/flink/pull/17985 which will introduce
the config option,
so we can continue working on the CAST fixes and improvements. It will be
very easy to flip
the default behaviour (currently on the PR: legacy = ENABLED) when this
discussion concludes,
and update the
I definitely understand the argument to continue supporting the existing
(return null) as the default behaviour.
I'd like to point out though that if we decide this (option no.2) it's kind
of unnatural, to directly drop the flag in *Flink 2.0*
for example, and force the users at that point to use
Hi all,
My conclusion at this point is that there is consensus that the default
behaviour of CAST should raise errors when it fails and that it should be
configurable via a configuration flag.
The open discussion is on when we want to fix the current (incorrect)
behaviour:
1. Doing it in the
> This is what I don't really understand here: how adding a configuration
option causes issues here?
This is why: for most Flink production use cases I see, it's not like a
couple of people manage ~5 Flink
jobs, so they can easily track all the big changes in every minor Flink
version. Typically
> NULL in SQL essentially means "UNKNOWN", it's not as scary as a null in
java which will easily cause a NPE or some random behavior with a c++
function call.
This is true from the user point of view, except our runtime doesn't treat
null as some value where you can safely execute operations and
Hi Francesco,
Thanks for sharing your opinion about this and examples with other
programming
languages. I just want to mention, that NULL in SQL world is a bit
different with the
meaning in programming languages like java.
NULL in SQL essentially means "UNKNOWN", it's not as scary as a null in
Hi all,
tl;dr:
I think Timo pretty much said it all. As described in the issue, my
proposal is:
* Let's switch the default behavior of CAST to fail
* Let's add TRY_CAST to have the old behavior
* Let's add a rule (disabled by default) that wraps every CAST in a TRY, in
order to keep the old
Hi Timo,
Regarding CAST, I think no one denies the standard behavior which should
raise errors when
failed. The only question is how do we solve it, given lots of users
already relying on current
more tolerant behavior. Some violation of standard but acceptable behavior
doesn't deserve
a breaking
Hi everyone,
thanks for finally have this discussion on the mailing list. As both a
contributor and user, I have experienced a couple issues around
nullability coming out of nowhere in a pipeline. This discussion should
not only cover CAST but failure handling in general.
Let me summarize
Sorry I forgot to add user ML. I also would like to gather some users
feedback on this thing.
Since I didn't get any feedback on this topic before from users.
Best,
Kurt
On Thu, Nov 18, 2021 at 6:33 PM Kurt Young wrote:
> (added user ML to this thread)
>
> HI all,
>
> I would like to raise a
(added user ML to this thread)
HI all,
I would like to raise a different opinion about this change. I agree with
Ingo that
we should not just break some existing behavior, and even if we introduce an
option to control the behavior, i would propose to set the default value to
current
behavior.
I
Hi,
first of all, thanks for the summary of both sides, and for bringing up the
discussion on this.
I think it is obvious that this is not something we can just "break", so
the config option seems mandatory to me.
Overall I agree with Martijn and Till that throwing errors is the more
expected
Hi everyone,
personally I would also prefer the system telling me that something is
wrong instead of silently ignoring records. If there is a TRY_CAST function
that has the old behaviour, people can still get the old behaviour. For
backwards compatibility reasons it is a good idea to introduce a
Hi Caizhi,
Thanks for bringing this up for discussion. I think the important part is
what do developers expect as the default behaviour of a CAST function when
casting fails. If I look at Postgres [1] or MSSQL [2], the default
behaviour of a CAST failing would be to return an error, which would
Hi devs!
We're discussing the behavior of casting functions (including cast,
to_timestamp, to_date, etc.) for invalid input in
https://issues.apache.org/jira/browse/FLINK-24924. As this topic is crucial
to compatibility and usability we'd like to continue discussing this
publicly in the mailing
17 matches
Mail list logo
