Генератор клиента к базе данных на Golang на основе интерфейса

[@helgihabr]

Т.е. каждый раз описывать структуру БД?
Почему не сделать, например, метод Load, который загрузит строку из любой таблицы и разложит в map данные, согласно названиям полей:

map[string]interface{}{
    "id": 1,
    "name": "Some"
...
}

И потом иметь Set и Get для работы с этими полями.

[@zaurio]

В том то и дело, что не структуру БД. Подход к описанию контракта в статически типизированном виде предпочтительнее работы с моделями базы данных, это типичная практика. Например потому что ответ от базы не всегда соответствует таблицам в базе.

[@helgihabr]

Начал смотреть код на гитхаб, я правильно понял, что его нельзя в параллельных горутинах использовать?

[@zaurio]

Конкурентный доступ к объекту DB обеспечивает драйвер, конкурентный доступ к кэшу prepared statements обеспечен библиотекой на базе mutex.

Можно.

[@helgihabr]

Понял, спасибо. Просто закралось сомнение, что эта часть безопасна для гоурутин:
https://github.com/go-gad/sal/blob/master/looker/reflect.go#L133

[@zelenin]

    GetRubrics(ctx context.Context, req GetRubricsReq) (GetRubricsResp, error)

при запросе 100000 строк здесь будет слайс из 10000 инстансов? кажется здесь курсор/итератор должен возвращаться.

[@zaurio]

На 100_000 строк из базы данных будет слайс из 100_000 элементов. Курсор должен запрашиваться явно. В данном случае поведение соответствует ожиданию.

[@zelenin]

Курсор должен запрашиваться явно.

GetRubricsResp — если это будет курсором, то явность его запрашивания будет зашкаливать. Не в этом дело, а в апи, сгенерированном тулзой. Из курсора я могу получить слайс, из слайса курсор нет. Таким образом тулза покрывает один кейс, а могла бы два.
db-слой по умолчанию должен возвращать итератор, а вот что с ним уже делать, решит конечный пользователь.