tap-stackexchange

[edgarrmondragon]

https://api.stackexchange.com/docs/

[edgarrmondragon]

Started work on this...

[edgarrmondragon]

@aaronsteers It's starting to look complete: https://github.com/edgarrmondragon/tap-stackexchange

Few things to note:

• requests-cache only supports Python>=3.7
• .meltano not included in .gitignore
• —about —format=markdown is missing information data types
• Personal choice: target-sqlite over target-jsonl
• TODO: Heavily rate-limited, perfect guinea pig for a reference implementation of request caching

[aaronsteers]

requests-cache only supports Python>=3.7

We'd have to research the impact, but I'd be okay dropping 3.6 support, or if feasible, supporting caching only when python version is >=3.7. What do think about the best course?

—about —format=markdown is missing information data types

This is known - at least on my side, I'm aware. The challenge is that json schema types don't always resolve neatly into a single type. So, for v1 at least, I was happy to just keep that untouched for now. As much as it seems like data types are a notable omission, there's also a counter argument that (at least for the readme), we can put that burden on the "description" field and/or a natural inference.

What do you think?

[edgarrmondragon]

We'd have to research the impact, but I'd be okay dropping 3.6 support, or if feasible, supporting caching only when python version is >=3.7. What do think about the best course?

I'm for dropping support for 3.6 altogether in the SDK. @pandemicsyn shared https://endoflife.date/python.

This is known - at least on my side, I'm aware. The challenge is that json schema types don't always resolve neatly into a single type.

I agree, though anyOf and allOf should be fairly uncommon for settings, and object and array could be expanded into something like

Setting	Type	Required	Default	Description
key	string	True	None	Describes Key
my_obj.nested_string	string	True	None	Describes {"my_obj": {"nested_string": "abcdef"}}
my_arr[].id	integer	True	None	Describes {"my_arr": [{"id": 123}, {"id": 456}]}

So, for v1 at least, I was happy to just keep that untouched for now.

I agree, this is not a huge deal.

As much as it seems like data types are a notable omission, there's also a counter argument that (at least for the readme), we can put that burden on the "description" field and/or a natural inference.

That makes sense, if there's any confusion about something like 9831 being a string or integer, the description should clear it.

Thanks for your comments @aaronsteers!

[pnadolny13]

@edgarrmondragon closing this issue since its on MeltanoHub already https://hub.meltano.com/taps/stackexchange!