Replies: 3 comments
-
Can you explain why the different package approach doesn't work for you? I'd rather not more complexity to query names, especially features that may not map directly to other programming languages. |
Beta Was this translation helpful? Give feedback.
0 replies
-
The main reason is that each generated package will contain a models.go,
which will duplicate the same structure across different packages. for
example, if there are 3 tables: authors, books and orders, it may end up 9
types
Author type: authors.Author, books.Author, orders.Author
Book type: author.Book, books.Book, orders.Book
Order type: authors.Order, books.Order, orders.Order
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Another reason is the current approach will easily generate one big interface with too many methods in it, which will be a pain to mock. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
With large project there will be huge amount of functions. It will be much better if we support named queries and interfaces. For example
Will generate:
With this named Queries and interfaces support, I don't need to split queries into different packages like #710
in order to categorise queries.
Beta Was this translation helpful? Give feedback.
All reactions