Anybody from Datamill here that can chime in? https://github.com/datamill-co/target-snowflake/issues/22 🙂

@andrew_madonna Can you please have a look at this?

@taylor @douwe_maan That’s currently expected behavior. I’m not against it, it’s just something we didn’t implement. If is does get implemented, I think I’d prefer to have it be part of the SQL target base code in target-postgres https://github.com/datamill-co/target-postgres

We're currently on a fork (https://github.com/Mashey/tap-zoom) but the bulk of the code is yours, yes. Nice work 😄

Yeah, all the forks are starting to get crazy. I’m on a project now that we’re using the BG target which is a fork of a fork. Part of that on the tap side is because Stitch has all but given up on open source maintenance, so no one can get a PR approved anyway.

We're planning to solve that with our upcoming Singer Hub! From https://meltano.com/docs/#embracing-singer:

We are also planning to grow Meltano's index of discoverable extractors and loaders into the Singer equivalent of PyPI or Docker Hub , to give users (and tools) a central place to learn about the behavior, supported features, and maintenance status of all taps and targets in the ecosystem, which are currently scattered across Git repos and PyPI packages. We will encourage decentralized maintenance of connectors to prevent individual organizations from becoming bottlenecks as the ecosystem grows, and will support the adoption of abandoned connectors by new maintainers.

We'll address the fork explosion issue by always having a single default well-maintained variant and letting poorly maintained taps/targets be adopted: https://gitlab.com/meltano/meltano/-/blob/c679549b8e0d01ced7f38ef7963c6ddc6525b0ba/docs/src/docs/contributor-guide.md#adopting-a-plugin

Nice! Yeah, a catalog that supports repos will be nice

Thanks for the feedback @andrew_madonna Looks like somebody else has a similar issue in the target-postgres project https://github.com/datamill-co/target-postgres/issues/198 I can close my issue and cross-link to the other issue. My thoughts for the general ecosystem is that it feels like the target should take care of schema creation, but I can understand the reasoning behind not doing it. I’ll advocate for the target SDK to have creation as a default but I’m sure we’ll include community feedback on the whole thing cc @aaronsteers 😄