You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should sqlc support separating packages for the query and schema structs, for when the number of queries grow? In the context of the ondeck example, maybe the user will want to have generated queries for Venue and City in separate packages, plus another package for queries that use both, plus a package for the generated schemas. This is contrived, but imagine there are dozens of tables, and at least a quadratic number of relations. At that point it would be useful to separate some queries into its own packages.
sqlc at the moment supports multiple packages, but does not support sharing schema across packages without duplicating the generated schema structs.
The text was updated successfully, but these errors were encountered:
I agree that this will become a problem for larger project. However, I'd like to pass on implementing a solution for now. It complicates the code generation quite a bit, and I don't think it's worth the effort right now.
As our users' applications grow and larger users adopt sqlc, we can revisit this.
My side project that I started using sqlc on already has 39 queries, and it already feels kind of excessive to keep in the same package. Too many methods on the Queries struct.
Should sqlc support separating packages for the query and schema structs, for when the number of queries grow? In the context of the
ondeck
example, maybe the user will want to have generated queries for Venue and City in separate packages, plus another package for queries that use both, plus a package for the generated schemas. This is contrived, but imagine there are dozens of tables, and at least a quadratic number of relations. At that point it would be useful to separate some queries into its own packages.sqlc at the moment supports multiple packages, but does not support sharing schema across packages without duplicating the generated schema structs.
The text was updated successfully, but these errors were encountered: