dstandish commented on code in PR #23317:
URL: https://github.com/apache/airflow/pull/23317#discussion_r897273586


##########
airflow/models/dagwarning.py:
##########
@@ -0,0 +1,93 @@
+#
+# 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.
+from enum import Enum
+
+from sqlalchemy import Column, ForeignKeyConstraint, Integer, String, Text, 
false
+
+from airflow.models.base import ID_LEN, Base
+from airflow.utils import timezone
+from airflow.utils.session import NEW_SESSION, provide_session
+from airflow.utils.sqlalchemy import UtcDateTime
+
+
+class DagWarning(Base):
+    """
+    A table to store DAG warnings.
+
+    DAG warnings are problems that don't rise to the level of failing the DAG 
parse
+    but which users should nonetheless be warned about.  These warnings are 
recorded
+    when parsing DAG and displayed on the Webserver in a flash message.
+    """
+
+    id = Column(
+        Integer, autoincrement=True, server_default='id'
+    )  # this default just signals to SQLA to defer to server

Review Comment:
   basically, if we want an integer surrogate key we have to make it actually 
the primary key and use a unique index for the logical key. but then to make 
sqlalchemy work properly, e.g. with function merge , then sqlalchemy has to 
think that the logical key is the primary key (even though it’s really not).  
finally, the server_default value is required otherwise you’ll get a null 
constraint violation cus it will try to populate the record with a null value.
   
   the alternative is, (1) no surrogate key, or (2) yes surrogate key but bad 
sqlalchemy behavior (e.g. merge will be unusable).  in this particular case, 
having a surrogate key doesn’t really make a difference. BUT i think it’s a 
“best” practice to have a surrogate key in general (for normalization 
concerns), so i think we should probably figure out an acceptable approach for 
it somehow or another.



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

Reply via email to