Облегчаем работу с SQL в go и при этом не отстреливаем себе ноги

[sashamelentyev]

Не смотрели в сторону entgo.io?

[Nurked]

Хм. Интересно, а чем обосновано ваше предложение? Я вот, прочитал статью и в ней автор пишет "не пользуйтесь фреймворками, себе дороже будет". Это если так выжать смысл. А вы в ответ постите ссылку на фреймворк.

[sashamelentyev]

Согласен. Не обдумано предложил. Вы правы.
На первый взгляд то что реализует описанный инструмент - пробежала ассоциация именно с тем инструментов ссылку на который оставил

[andreyiq]

Мы просто в бд создали для всего хранимые процедуры и написали сервис который обрабатывает рест запросы, по url определяется какую процедуру дергать, json конвертится во входные параметры для процедуры. Т.е. получился простой конвертер json->sql->json. Для всех хранимок генерится дока под сваггер. Служба очень маленькая на пару тысяч строк кода, зато больше не нужно писать на го, достаточно двух человек, один под sql пишет, второй фронт.

[Tatikoma]

Так, а если в базе поле с типом bytea и я хочу в него записать \x80 - как будет работать ваша API?

[andreyiq]

В чем проблема?

[Tatikoma]

В JSON. Как по-вашему будет выглядеть передача \x80 в JSON ?

[andreyiq]

Вы про всякие blob'ы? Они в base64 передаются

[Tatikoma]

Нет, blob - это binary large object. А тут один байт - \x80. Он тоже в base64? - Ну окей. Тогда у вас конвертер не в JSON, а в base64 + JSON. Костыли )

[andreyiq]

Если тип byte, то это Number в json, соответственно просто число передаться. Там сопоставление sql типов с json типами, соответственно простые типы передаются как есть, бинарные как base64. В json по другому не получиться. Go точно также конвертирует структуры в json

[andreyiq]

Нет, у хранимое сколько угодно параметров, просто rest запрос конвертиться в sql запрос

[neuterm]

Нет интересного опыта интеграции Golang и OracleDB?

[vtolstov]

А что там? есть gordor+sqlx вполне хватает. Или тут речь в контексте ORM ?

[vtolstov]

Куча конкатенаций строк при каждом вызове, создание мапов, никаких prepared statements, для продакшена - не вариант.

[Nurked]

Я помню как писал свой первый фреймворк на дотнете в 2005 году. К нам приходил препод в МЭСИ и говорил святую мантру:

Все запросы должгы быть prep statements! Иначе - капут.

С тех пор я всегда так и делал. А вот в 2017 году мне довелось переносить проект из SQL 2000 на SQL 2017. И я решил, что пришла пора подтвердить святые слова. Начал переносить всё на prep statements. Тут ко мне подошёл архитектор БД и спросил нафига я это делаю? Ну я давай оюъяснять и всё такое. А он мне в ответ: забей, мы не в 2001 году. БД сама разберётся.

Я замерил производительность, и что бы вы думали? MSSQL отлично автоматом загонял однотипные запросы в кеш. Скорость была идентичной. Да и переносить логику в БД не надо.

[vtolstov]

Мой коммент нужно читать целиком, все слова связаны. =)

Я согласен, что на текущий момент производительность может быть и примерно одинаковая, но поток трафика от клиента бд к серверу все же влияет. И тем более, если средства бд языка и тп позволяют общаться более эффективно, зачем упускать эту возможность? Большинство запросов это не короткая строчка из 20-50 символов. В приложениях зачастую один запрос на 50 строк. Зачем его слать постоянно на сервер бд?

[Tatikoma]

Затем что у тебя может быть кластер баз и твой prepared statement существует только в рамках одного инстанса. И по хорошему ты не должен знать на какой инстанс идёшь, потому что инстанс для тебя выбирает отказоустойчивый прокси, для большей производительности находящийся в режиме transaction pooling. Поэтому ты так или иначе каждый раз должен слать запрос.

[vtolstov]

ну что там за прокси это вопрос, зачем знать инстанс ?

я все равно не вижу, почему должно быть оправданным выделение памяти каждый раз на конкатенацию кучи строк, про прокси сейчас не скажу, но pgbouncer норм работает с этим

[Tatikoma]

Поставьте pgbouncer.ini настройку и проверьте ещё раз работу prepared statements (под нагрузкой):

 pool_mode=transaction