potiuk commented on code in PR #35868:
URL: https://github.com/apache/airflow/pull/35868#discussion_r1413040413
##########
airflow/migrations/versions/0027_1_10_0_add_time_zone_awareness.py:
##########
@@ -139,11 +139,11 @@ def upgrade():
type_=mysql.TIMESTAMP(fsp=6),
)
else:
- # sqlite and mssql datetime are fine as is. Therefore, not converting
Review Comment:
Yeah. It was a "little" weird. But I could go either way.
> The removal of MsSQL support from our side just means that we do not test
Airflow deployment against MsSQL backend. It doesn't mean that it won't work it
just mean that we don't guarantee it.
I think we need a a bit more than that.
There are two potential scenarios for our MSSQL current users:
1) Scenario 1 - we do not hard/stop mssql users for migration and it will
maybe work and maybe not
If we leave it in "maybe it will work" then our users will continue using
airflow until it breaks and willl come to us when it will stop (inevitably) -
the whole point is that the "mssql-specific" code in Airflow slows us down, so
getting rid of it is a good idea and also it's likely in a few months time, it
will catastrophically break MSSQL installation - say somoene already moved to
2.9.0 - still using MsSQL and then it will break in 2.10.0. Now. they have no
way to go back (becuase migration scripts will also break for example) and we
have a user who has broken installation that they can do nothing about.
And they will complain to us, will take our time, will cry for help and
workarounds regardless what is the status of MSSQL - and most of all they will
loose the trust in Airflow as a good solution for them because it won't work
for them for possibly days when they will try to recover somehow. And this all
will be happening 2 years from now when nobody here will even remember what
kind of changes they were there implmented and likely many of people who are
now in Airflow won't even be around.
And this is actually one of the reasons we want to remove MSSQL - we do not
WANT to get issues about MSSQL for 2.8+
Is it their fault? Technically yes - they have not read the release notes (I
have no stats but there is quite a number of people who don't).
2) Scenario 2 - we forbid MSSQL and remove MSSQL code straight away
We can explicitly forbid migration to 2.8.0 for MSSQL users. that will be
much cleaner solution. We will provide them the migration script on 2.7.3 and
how to migrate to other database. The users will see it immediatley when they
will attempt to migrate - and they will have two choices: a) stay with Airflow
2.7.3 longer b) migrate to other DB.
I think this is far more plausible scenario - both for our users and
maintainers (including future ones) of Airflow. The cut is clean, and we know
already that (some) people do not read release notes so basically - if we allow
MSSQL users to migrate to 2.8.0, then it's all but guaranteed that some of our
users will actually get into troubles sooner or later. We are basically
accepting the fact that some percentage of our users, rather than stopped from
migration - will migrate and eventually get in the troubles.
So I'd personally be for even saying:
```
if mssql => raise Error ("Migrate to Postgres or MySQL").
```
--
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: commits-unsubscr...@airflow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
