Обновить

Комментарии 12

Интересно. А в sqlx есть же namedQuery , он как будто решает частично то же самое. В чем отличия с вашим билдером, какое преимущество? Не ради похаять, действительно интересно. Я сам таких динамично меняющихся запросов не пишу, предпочитаю чистый SQL в отдельном файле, чтобы код не засорял визуально. Но вдруг понадобится.

В sqlx namedQuery помогает в сборе ответа от БД в структуру, но сам запрос все равно пишется на сыром SQL. Я хотел отойти от чистого SQL и перейти в сторону кода на Go с использованием полей структур как колонок БД.

Могу посоветовать посмотреть на sqlc, если используете SQL в отдельных файлах. Sqlc как раз хорошо с таким работает.

Ну звучит это Go Way на мой скромный взгляд. Если там под капотом рефлексии дикой нет, то может даже взлетит. Удачи вам.

Я не go разработчик, но с удивлением вынужден накинуть тезис, что в плане работы с sql запросами в коде современный якобы заточенный под бэкенд язык как-то из коробки не сильно удобнее, чем VBA в том же MS Access 2003. Упомянутые в статье подходы визуально не сильно улучшают ситуацию, хотя, вероятно, это дело привычки.

Лучше в каком плане?

Скуэль - пока лучшее что придумали для обработки табличных данных, причем его придумали чуть ли не 50 лет назад.

В индустрии есть проблема - множество программистов не освоивших скуэль,

Только свой базовый язык - питон пыху,

Они хотят выгрузить данные в приложение по быстрому и там обработать, им нужны всякие системы потому что скуль это "сложновая".

Я ожидал увидеть, что талантливые создатели языков придумают какие-то лаконичные синтаксические конструкции, упрощающие всю эту рутину по взаимодействию с базами данных, но по факту, количество кода, проверок, преобразований совсем не сократилось и подходы те же, что много лет назад. Хотя 1С-ники для упрощения жизни программистам не освоившим sql давно придумали мощную формочку с редактором текстов запросов, даже интересно, есть ли подобный функционал в современных средах разработки. Честно, сам не знаю как бы я хотел видеть удобный синтаксис работы с БД, но вижу, что борьба идет до сих пор. Могу лишь добавить что самый простой вариант работы со строчками и условиями хорош тем, что прост, понятен, без скрытых библиотек и и работает на всех языках в том или ином виде.

Ради того чтобы просто не писать таблицу руками, которая никогда не меняется вы вместо https://github.com/masterminds/squirrel пишете своё....удачи)

При этом вы можете просто к DTO добавить метод TableName и в целом писпользовать тот же squirel, либо тупо ограничиться константами репозитория

Переименование таблицы не является проблемой, автор акцентирует внимание на

Переименовал колонку — удачи найти все строки "user_name" по проекту.

Всё-таки это в репозитории должно быть, а не во всем проекте

Ох, как я вас понимаю, дорогой топикстартер. С год/два назад в своем продуктовом проекте тоже написал свой билдер (qb), а сейчас, когда все более и менее устаканилось - буду переписывать обратно на raw sql, ибо все билдеры по итогу от лукавого. В отличии от эпохи “до билдера” - будет минимум рантайм манипуляций, все по максимуму на go generate + embed.

Очень знакомые проблемы. Попробую на рабочих проектах.

Прикольно. По синтаксису напоминает питоновскую sqlAlchemy.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации