vim+SQLUtilities

Что лучше использовать для чтения Body запроса: ioutil.ReadAll() или (b *Buffer) ReadFrom() из bytes?

Что-то мне подсказывает что они делают разные вещи

Здравствуйте. Подскажите orm для go максимально по синтаксису похожую на peewee orm из python

Здравствуйте. Подскажите orm для go максимально по синтаксису похожую на peewee orm из python

Не думаю, что орм для такое количество

Здравствуйте. Подскажите orm для go максимально по синтаксису похожую на peewee orm из python

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

Пяток это много кстати

Что лучше использовать для чтения Body запроса: ioutil.ReadAll() или (b *Buffer) ReadFrom() из bytes?

В зависимости от того что тебе там приходит , если тело json то я обычно через ioutill.ReadAll делаю , по бенчмаркам мерял самый быстрый способ был , если post с формой то в зависимости от параметров

кто как в REST API PATCH делает?

или частичный патч?

конкретизируй

вот у тебя есть REST PATCH, который принимает данные для частичного апдейта сущности. Ты его анализируешь и строишь уже к примеру апдейты к базе. Кто как делает это?

я думаю это зависит от db-слоя. если ормка, то апдейтишь поля у сущности, дальше орм сама сохрпаняет. если голый sql, то создаешь update из пришедших полей. Это ты хочешь знать?

есть варианты jsonpath2sql?

gorm кстати норм или что еще посоветуете?

Какой фреймворк посоветуете для написания апи, вот прям чтобы потом можно было и в продакшене юзать? Я пока на биго остановился, пользуется им кто-нибудь?

Можно и стандартный использовать

обсуждение фреймворков здесь близко к нулю, потому что ими никто не пользуется

Каждый раз когда заходят такие разговоры, понимаю, насколько хорошо что в Го есть достаточно много стандартных хороших либ на все случаи жизни

Просто писать апи с тем же гориллой? вроде довольно удобен, но не шибко быстрый, а net/http слышал что не особо много в проде работает, или не правда?

Какой фреймворк посоветуете для написания апи, вот прям чтобы потом можно было и в продакшене юзать? Я пока на биго остановился, пользуется им кто-нибудь?

gin простой и быстрый

Какой фреймворк посоветуете для написания апи, вот прям чтобы потом можно было и в продакшене юзать? Я пока на биго остановился, пользуется им кто-нибудь?

go-chi

Просто писать апи с тем же гориллой? вроде довольно удобен, но не шибко быстрый, а net/http слышал что не особо много в проде работает, или не правда?

а биго наверное шустрый, да?

про net/http не в проде - смешно =) только он везде и в проде

Люблю gin, но это лично мое мнение, не подкреплённое никакими измерениями

go-chi

+1 только это роутер, не фреймворк

кто как в REST API PATCH делает?

Никак. Не работает оно

про net/http не в проде - смешно =) только он везде и в проде

А как же fasthttp?

А как же fasthttp?

там что-то давненько комитов не было

там что-то давненько комитов не было

и шо?

он от этого менее стабильным не стал

А как же fasthttp?

а что с ним?

подскажите пожалуйста проект лежит по пути /Users/milkiweed/go/src/bolsche в директории 2 файла , все начинаются со строк package bolsche прописывал команды go install bolsche, все завершалось без ошибок но когда ввожу go run и любой файл из моей директории - получаю > go run: cannot run non-main package указывал GOPATH, проект уже туда кинул и следовал советам, которые удалось нагуглить; ничего толкового не нашел

в го executable только main пакеты

а что с ним?

с ним все хорошо

к чему тогда ваш вопрос?

к чему тогда ваш вопрос?

вы утверждаете что только net/http в проде, что совсем не так.

в го executable только main пакеты

а что это значит? немного не понял как в данной ситуации лучше поступить?

вы утверждаете что только net/http в проде, что совсем не так.

я пренебрёг десятыми долями процента

а что это значит? немного не понял как в данной ситуации лучше поступить?

можно начать с изучения го тура, там как раз в первой лекции про это https://tour.golang.org/basics/1

я пренебрёг десятыми долями процента

Почему стандартный net/http используется реже чем fasthttp?

всё ровно наоборот

Почему стандартный net/http используется реже чем fasthttp?

потому что штатный медленнее и аллоцирует память на каждый чих )

всё ровно наоборот

Да, наоборот, ошибся. Так почему?)

потому что он 1) удобнее 2) достаточно быстр для любых задач 3) более функционален 4) поддерживаешься более широким наборот библиотек 5) более стабилен

можно и дальше продложать, вроде поддерживает http2 итд

потому что он 1) удобнее 2) достаточно быстр для любых задач 3) более функционален 4) поддерживаешься более широким наборот библиотек 5) более стабилен

В п2 есть очевидное противоречие :)

какое?

какое?

Достаточно быстр для любых задач

Он либо для любых, либо достаточно быстр :)

хорошо, 99 процентов любых задач

Какой фреймворк посоветуете для написания апи, вот прям чтобы потом можно было и в продакшене юзать? Я пока на биго остановился, пользуется им кто-нибудь?

beego - монстр, имхо. Есть стандартный пакет, есть echo, есть chi. Для прода есть swagger+генерация, есть grpc с генерацией

а биго наверное шустрый, да?

Ы)))

а что это значит? немного не понял как в данной ситуации лучше поступить?

Запускаемый файл должен первой строчкой package main иметь

@CheshireKot я не помню ты или не ты говорил, но qml разве имеет зависимость на js ? К тому же сразу на v8?

@CheshireKot я не помню ты или не ты говорил, но qml разве имеет зависимость на js ? К тому же сразу на v8?

qml-движок носит внутри себя v8, который js-движок, и с ним работает

когда ты биндишь что-то из основного приложения, допустим, на C++, в QML-интерфейс, создается соответствующий js-объект, с которым твой интерфейс и работает

Никак. Не работает оно

а чего так? хочу с клинта слать дельту по стандарту https://tools.ietf.org/html/rfc7386. как на сервере лучше всего с этим жить?

Или с https://tools.ietf.org/html/rfc6902

иначе придется слать на сервер всю сущность и на сервере вычислять дельту с вариантами 1) запоминать все версии сущностей, вычислять дельту по сравнению с нужной версией 2) придумывать блокировки на время редактирования 3) не придумывать блокировки и слать клиента лесом если он пытается изменить устаревшую версию.

как можно преобразовать строку типа 20180805213000 +0300 в unix timestamp

почитайте доку к time пакету

там есть Parse и формат по которому парсить

иначе придется слать на сервер всю сущность и на сервере вычислять дельту с вариантами 1) запоминать все версии сущностей, вычислять дельту по сравнению с нужной версией 2) придумывать блокировки на время редактирования 3) не придумывать блокировки и слать клиента лесом если он пытается изменить устаревшую версию.

Можно обычным POST на специальный location типа. /entity/delta

в вашем случае parse будет что-то вроде time.Parse("20060102150405 -0700", yourVar), а затем time.Unix()

Можно обычным POST на специальный location типа. /entity/delta

все придумали до нас. PATCH у REST для этого. И вопрос в том как с этим работать на сервере

руками 🙂

А в чем проблемы то с PATCH?

Можно определить структуру, в неё анмаршалить JSON, и написать метод Merge(entity *YourEntity) в которой сравнить все поля, и по очередно обновить, либо рефлексией.

А в чем проблемы то с PATCH?

В натягивании бизнес-логики на скудное количество http verbs

можно кодогенерацией решить такой кейс, если проблема все таки не в http verbs а в лени все это описывать

Можно определить структуру, в неё анмаршалить JSON, и написать метод Merge(entity *YourEntity) в которой сравнить все поля, и по очередно обновить, либо рефлексией.

1) ты как делаешь? с клиента дельту получаешь или все состояние сущности? 2) как сохранение в базу у тебя выглядит?

put заменяет существующую сущность, patch меняет отдельные поля, не?

ну даже если дельту, нужно как-то связывать значение новый старый, например по ID, а дальше кодогенерацией создать if newEntity.Name != "" && newEntity.Name != oldEntity.Name { // добавляем в update значение }

а в чем вообще проблема обновить всю строку?

если уж раз с базой работаете?

https://github.com/imdario/mergo

вот структуры мерджить

https://github.com/evanphx/json-patch

а вот и json patch, но я думаю вы это видели