Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Generating named queries and interfaces#711

Unanswered
digitive asked this question inIssue Triage
Discussion options

With large project there will be huge amount of functions. It will be much better if we support named queries and interfaces. For example

-- name: Author.Get :oneSELECT * FROM authorsWHERE id = $1 LIMIT 1;-- name: Author.List :manySELECT * FROM authorsORDER BY name;-- name: Book.ListByAuthor :manySELECT * FROM books WHERE authorId = $1;

Will generate:

type AuthorQuerier interface {    Get(ctx context.Context, id int) error    List(ctx context.Context) ([]Author, error)}var _ AuthorQuerier = (*AuthorQueries)(nil)type BookQuerier interface {    ListByAuthor(ctx context.Context, authorId int) ([]Book, error)}var _ BookQuerier = (*BookQueries)(nil)...func NewAuthorQueries(db DBTX) *AuthorQueries {    return &AuthorQueries{db: db}}type AuthorQueries struct {    db DBTX}...type BookQueries struct {    db DBTX}func NewBookQueries(db DBTX) *BookQueries {...}

With this named Queries and interfaces support, I don't need to split queries into different packages like#710
in order to categorise queries.

You must be logged in to vote

Replies: 4 comments

Comment options

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.

You must be logged in to vote
0 replies
Comment options

The main reason is that each generated package will contain a models.go,which will duplicate the same structure across different packages. forexample, if there are 3 tables: authors, books and orders, it may end up 9typesAuthor type: authors.Author, books.Author, orders.AuthorBook type: author.Book, books.Book, orders.BookOrder type: authors.Order, books.Order, orders.Order
You must be logged in to vote
0 replies
Comment options

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.

You must be logged in to vote
0 replies
Comment options

A slightly different tack would be to have separate files with queries, where each file would result in a separate interface. The mapping could either be defined in the SQL source code with a meta-data comment "at file level" or as a mapping in the sqlc.yaml.

The generic interface nameQueries indicates that this dimension isn't well used. So far we have gone for the multiple package approach and lived with the duplication.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Labels
None yet
3 participants
@digitive@kyleconroy@fleipold
Converted from issue

This discussion was converted from issue #711 on September 12, 2020 23:29.

[8]ページ先頭
©2009-2025 Movatter.jp