+1. And I would also connect this with quite a revamp of connection behaviour (especially w/regards to UI and custom fields).
Those are very connected and the way it is done now is really, really terrible (I did backwards-compatible implementation of some of it when we split into providers and I can tell some horror stories on how bad it turned out). This ghost of the past should be killed in Airflow 3. On Sun, Feb 27, 2022 at 6:40 PM Brent Bovenzi <[email protected]> wrote: > +1 > > On Sat, Feb 26, 2022 at 11:58 AM Tomasz Urbaszek <[email protected]> > wrote: > >> > > Should we provide some way of validating existing connections so >> users can check this before upgrading to 3.0? >> > Sounds like a good idea >> >> I think we may consider refreshing the airflow upgrade scripts >> >> On Fri, 25 Feb 2022 at 22:04, Daniel Standish >> <[email protected]> wrote: >> >>> > What does this mean for the extra and extra_dejson attrs that exist on >>> Connection right now? >>> >>> It's a good question. I think ideally we should deprecate extra_dejson, >>> and `extra` should be dict (require json-encodable), with a db type of JSON >>> where supported. But the path to get there seems a little murkier. >>> Deprecating extra_dejson would be straightforward. But how would you >>> deprecate extra as string, while enabling folks to migrate to extra as dict >>> in place... Maybe make it a `str` subclass that implements `get`? >>> >>> Something like this: >>> >>> class ExtraDict(str): >>> >>> def __getitem__(self, item): >>> return json.loads(self)[item] >>> >>> def get(self, item, default=None): >>> return json.loads(self).get(item, default) >>> >>> >>> So then it behaves mostly like a string, but can also be accessed like a >>> dict? >>> >>> What do you think? >>> >>> > Should we provide some way of validating existing connections so users >>> can check this before upgrading to 3.0? >>> >>> Sounds like a good idea. >>> >>> >>>
