Conflicts in the "module 'zapatos/schema'" when multiple schemas for different dbs used in same project

[sahil87]

We have two different databases, with two different schemas, maintained in two different repos (Say A and B).

When both A and B get imported into the same third repo (say C), because of using /// <reference types="./zapatos/schema" /> twice, I get the following error:

Am I using this in an unintended way or doing something wrong?

[jawj]

Hmm — with the new ambient declaration design, I'm not sure there's any way to support multiple DBs in once codebase. Happy to be corrected if anyone can work this out.

[sahil87]

To make the problem simpler, I am not really trying to run queries in two DBs in the same repo.

I use SQL as the source of truth to decide the shape of my objects.
Because Zapatos was so handy, apart from its primary use to write queries, I also used the types generated by Zapatos to typecast the responses from a lot of APIs (the shape of which generally tracks the shape of the DB Schema). This specific use-case is where it's not usable now.

(The only option I have in the current situation is to stick to v2.0.1)

[jawj]

Hmm, this seems related to #49. The question is if we can find a new way of using the generated types from the Zapatos code that works for everyone, and doesn't involve copying the module wholesale into your code tree ...

[TheNickmaster21]

As an alternative to always exporting as 'zapatos/schema', it could be useful to be able to define the module name in the configuration file. That way one could configure each database to generate a differently named module and no other changes would be necessary.

[jawj]

As an alternative to always exporting as 'zapatos/schema', it could be useful to be able to define the module name in the configuration file. That way one could configure each database to generate a differently named module and no other changes would be necessary.

I don't think this would work, I'm afraid, since the shortcuts all refer to zapatos/schema to get their types.

See also related discussion in #49 about whether to bring back the v2 approach alongside the v3 approach.

[jawj]

Closing this since the solution — bringing back the v2 approach of copying code as an option — seems to be common with #49.