dabla commented on PR #41327: URL: https://github.com/apache/airflow/pull/41327#issuecomment-2326753141
> I think in mssql provider, we do have a few "loosely related" things in providers already and cross-provider dependencies (both explicit and implicit) and sometimes where things are "between" we make arbitrary decisions. > > When we introduced providers we implement a bit "soft and not 100% compilable" rule on where to put such things and the rule is .... > > "Where it would be likely maintained best by the major stakeholder of the provider - assuming there is one" > > For example when we have S3 -> GCS transfer operator we put it in Google Provider and GCS-> S3 we put it in Amazon provider. The very "soft" and "political" reason for that is that Amazon will be keen on bringing data from GCS and migrating people over from Google and Google will be keen on bringing the data from S3 to GCS. > > Not very scientific, I know and sometimes you can argue the decision, but it's best "rule of thumb" we can have on that. > > So Assuming that Microsoft (which is not happening BTW) is the key stakeholder in `mssql` provider - would they want to maintain ODBC dialect there? I certainly think so. Is there anyone who owns "ODBC" who would be interested in maintaining MSSQL dialect there ? While ODBC came from Microsoft, it's a long time "de-facto" standard and there are some independent bodies that standardized the specification https://en.wikipedia.org/wiki/Open_Database_Connectivity - so I think those standard bodies would prefer each "specific" dialect is maintained by whoever is interested in the particular dialect. > > So `mssql` seems like a good place to put it. Thank you @jarek for your fast and elaborate answer, what you are saying makes sense and is indeed logical. Will try to implement those changes as quickly as possible. Thanks again :) -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
