eladkal commented on code in PR #26217: URL: https://github.com/apache/airflow/pull/26217#discussion_r965168224
########## docs/apache-airflow/database-erd-ref.rst: ########## @@ -0,0 +1,23 @@ + .. Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +ERD Schema of the Database +'''''''''''''''''''''''''' + +Here is the current Database schema diagram. Review Comment: The DB is part of Airflow deployment so users should be aware of it and to be able to understand migrations. However that is very narrow window of before/during migration and even so the issues are most likely about specific problems where the **data context is irrelevant** it's just about column type / index etc. So you don't care what the data/structure represent you just care about finishing migrations with no issues. When a user is asking to see ERD diagram his intention is to **study** the application and possibly make some integration to the DB **directly**. The data context is interesting for this. You really care about what the structure represent. This is OK when you want to be a developer of application (like contributing to Airflow in our case) but wrong for other cases (at least to my taste). Regardless of if ERD will be on website or internal in /dev we should have a website entry that explain it's risky to rely directly on the DB tables. We can also have this explanation and mention that if for some reason someone needed the ERD for a valid use case that we didn't think about they can find it in the repo via the contribution guide. I think this is a good balance between not "inviting abuse" yet not make it really hard to find for people who understand the risk and choose to take it. -- 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]
