Hello, I am glad of such an interesting discussion. I have updated the documentation to use objectType: object. https://github.com/apache/airflow/pull/8721
Best regards, Kamil Breguła On Sun, May 31, 2020 at 12:04 PM Jarek Potiuk <jarek.pot...@polidea.com> wrote: > > Yep did it exactly this way :). Even Map<Object, Object> works so I am > super happy. > > J. > > On Sun, May 31, 2020 at 12:00 PM Driesprong, Fokko <fo...@driesprong.frl> > wrote: > > > In Java this isn’t an issue. With Jackson you would just read the field as > > a Map<String, Object> and check if the items are available in the map. The > > Object can also be a dictionary or array. No need to recompile, but you > > need good errorhandling in case a key isn’t present. > > > > Cheers, Fokko > > > > Op zo 31 mei 2020 om 09:11 schreef QP Hou <q...@scribd.com> > > > > > I wrote up a quick a go example that uses runtime reflection to work > > > with object design based off Kamil's java example: > > > > > > > > https://github.com/houqp/airflow-api-clients/blob/master/out/object/go/model_dag_run_test.go > > > . > > > > > > Code wise, it's indeed a little bit more verbose compared to > > > deserializing/serializing a string. The tradeoff here is it's > > > verbosity v.s. type safety. > > > > > > On Sat, May 30, 2020 at 2:31 AM Jarek Potiuk <jarek.pot...@polidea.com> > > > wrote: > > > > > > > > Ash - QP: also - as Kamil mentioned he already generated multiple > > clients > > > > in > > https://github.com/mik-laj/airflow-api-clients/tree/master/out/object > > > > so if you have time , maybe you can also take a look in parallel. > > > > > > > > On Sat, May 30, 2020 at 11:29 AM Jarek Potiuk < > > jarek.pot...@polidea.com> > > > > wrote: > > > > > > > > > Kamil - I believe you already have those clients generated - so i > > will > > > use > > > > > them from there. > > > > > > > > > > J,. > > > > > > > > > > On Sat, May 30, 2020 at 11:26 AM Jarek Potiuk < > > > jarek.pot...@polidea.com> > > > > > wrote: > > > > > > > > > >> OK. Indeed there seem to be quite some ambiguities and > > inconsistencies > > > > >> and the knowledge we are basing our discussion on is a bit > > fragmented > > > > >> and "abstract". > > > > >> > > > > >> Sorry for being a bit pushy but I think we are not doing enough as a > > > > >> community to make life our users easier, and we sometimes seem to > > > > >> proceed without fully understanding of consequences for them - > > > > >> downplaying the importance of it. And for public API I think this > > is a > > > > >> very important topic. > > > > >> > > > > >> I think there is an easy way to get a better understanding - simply > > > > >> use the OpenAPI generator to generate both - clients (in a few > > > > >> languages) and server stubs (in python) for Airflow and become the > > > > >> "user" and try to use the client + server and see where we get from > > > > >> there. This will haunt us for a long time if we make the wrong > > > > >> decision here. > > > > >> > > > > >> For me - this is one of the most important factors on how easy it > > will > > > > >> be for someone to use the API once we release it. And being able to > > > > >> use generated clients in several languages is pretty much > > > > >> non-negotiable requirement for the API. > > > > >> > > > > >> I will spend some time over the weekend trying it out and see > > whether > > > > >> the problems that I pointed out are really present in our specs and > > if > > > > >> they are - whether can be solved quickly - and if there are problems > > > > >> and they need some workarounds or customizations - for me it's super > > > > >> important that we are aware of those problems and we let the users > > of > > > > >> our API know how to solve them > > > > >> > > > > >> I will be posting some results while I do so - I count on your help > > QP > > > > >> and Ash if I see any non-obvious obstacles. > > > > >> > > > > >> J. > > > > >> > > > > > > > > > > > > > > > -- > > > > > > > > > > Jarek Potiuk > > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > > > > > > > > > > > -- > > > > > > > > Jarek Potiuk > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/>
