Stitch schema differs depending on target database support for nested fields

[lrpauley]

This package is really helpful, thanks for building it. One issue we've run into is that Stitch is structuring our data slightly differently than what's expected by this package. Fields structured as arrays in the Adwords schema (e.g. the labels field in the ad_groups model) are being stored as separate tables rather than as fields containing nested data (we're using Redshift as our target database). Sorry if I'm missing something easy configuration-wise.

We could handle this problem on our end by writing some dbt models on top of the Stitch source data to put the data into the form this package expects, or by forking the repo and modifying the schema to match what Stitch is generating (found an example of someone else doing that as well).

I'm happy to go with one of those solutions if that's the best path forward. It this is something you think would be good to support within the package itself, I'd also be willing to try to put together a PR for that.

[drewbanin]

Hey @lrpauley - thanks for opening this issue! This is something we're thinking harder about these days.

In general, I'd recommend making those base translation models you're referring to, but in this case, it might be challenging to construct a nested array of labels on Redshift, right?

In the near-term, I think forking and adjusting as needed could be a good idea, but keep an eye out for updates here as we make dbt better able to support this kind of database-aware logic switching in packages!

[lrpauley]

Makes sense! Thanks for the quick response. I'll work around it for now and keep an eye out for updates.