t; ORM class).
> >>
> >> To me the benefit would be a more logically structured code base,
> >with
> >> classes stored where you’d initially expect them to be, instead of
> >having
> >> to know upfront if they’re ORM classes or not.
> >>
>
of
>having
>> to know upfront if they’re ORM classes or not.
>>
>> I’ve explained the plan in more detail in the AIP:
>>
>https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-22%3A+Group+ORM+models+by+their+logical+usage+instead+of+type
>> <
>>
>
gt;> to know upfront if they’re ORM classes or not.
>>
>> I’ve explained the plan in more detail in the AIP:
>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-22%3A+Group+ORM+models+by+their+logical+usage+instead+of+type
>> <
>> https://cwiki.apache.org/
not.
>
> I’ve explained the plan in more detail in the AIP:
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-22%3A+Group+ORM+models+by+their+logical+usage+instead+of+type
> <
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-22:+Group+ORM+models+by+their+logical+u
+instead+of+type<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-22:+Group+ORM+models+by+their+logical+usage+instead+of+type>
and wonder if others think the same about it.
Needless to say, this would be a breaking change and only possible in Airflow
2.0.
Cheers,
Bas
