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 complaint 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