Comments 8
Т.е. каждый раз описывать структуру БД?
Почему не сделать, например, метод Load, который загрузит строку из любой таблицы и разложит в map данные, согласно названиям полей:
И потом иметь Set и Get для работы с этими полями.
Почему не сделать, например, метод Load, который загрузит строку из любой таблицы и разложит в map данные, согласно названиям полей:
map[string]interface{}{
"id": 1,
"name": "Some"
...
}
И потом иметь Set и Get для работы с этими полями.
В том то и дело, что не структуру БД. Подход к описанию контракта в статически типизированном виде предпочтительнее работы с моделями базы данных, это типичная практика. Например потому что ответ от базы не всегда соответствует таблицам в базе.
Начал смотреть код на гитхаб, я правильно понял, что его нельзя в параллельных горутинах использовать?
Конкурентный доступ к объекту DB обеспечивает драйвер, конкурентный доступ к кэшу prepared statements обеспечен библиотекой на базе mutex.
Можно.
Можно.
Понял, спасибо. Просто закралось сомнение, что эта часть безопасна для гоурутин:
https://github.com/go-gad/sal/blob/master/looker/reflect.go#L133
https://github.com/go-gad/sal/blob/master/looker/reflect.go#L133
GetRubrics(ctx context.Context, req GetRubricsReq) (GetRubricsResp, error)при запросе 100000 строк здесь будет слайс из 10000 инстансов? кажется здесь курсор/итератор должен возвращаться.
На 100_000 строк из базы данных будет слайс из 100_000 элементов. Курсор должен запрашиваться явно. В данном случае поведение соответствует ожиданию.
Курсор должен запрашиваться явно.
GetRubricsResp — если это будет курсором, то явность его запрашивания будет зашкаливать. Не в этом дело, а в апи, сгенерированном тулзой. Из курсора я могу получить слайс, из слайса курсор нет. Таким образом тулза покрывает один кейс, а могла бы два.
db-слой по умолчанию должен возвращать итератор, а вот что с ним уже делать, решит конечный пользователь.
Sign up to leave a comment.
Генератор клиента к базе данных на Golang на основе интерфейса