я не работал лично с джавой в контексте генерации SQL, но сталкивался с проблемами в общей системе, где есть компоненты на java, которые генерили тяжелые запросы и это поведение было неожиданно для разработчиков.
Я сталкивался с этим лишь тем, что я получал джава трейс с текстом запроса 🙂

В GORM я, имея довольно небольшой опыт, берусь предсказать все сгенеренные запросы и разновидностей в моих кейсах было не так много.
В основном это суб-сущности со связями 1 к1 или 1 ко многим.
Ну и query builder их вообще прозначен - прямо пишешь куски SQL.
Тут гадалкой стать не сложно - врубаешь дебаг режим и тестируешь приложение. В консоли все варианты запросов.

ок, спасибо, понял. А у джавы был hibernate?

👍

сложно сказать, я уволился оттуда в 2012 году 😄

Привет всем
Есть вопрос по гусю
Памагите
https://stackoverflow.com/questions/67635898/problem-in-migration-versioning-using-goose

всем привет

не могу понять почему 500 ошибку даёт , а курлом 422

 request1 := tool.NewRequestJson(url)
 request1.Header.AuthorizationBasic(UserName, Pass)

 res,err := request1.POST(req, &obj)
 fmt.Println("++++++++++++++", res.StatusCode)
if  res.StatusCode != http.StatusCreated {

Ваш вопрос не по гусю, а по git flow больше

Как может что-то попасть в stage, минуя develop ?

Например надо сделать хотфикс, версия дэва, стейджа и прода разная
И надо что-то зафиксить минуя дэв

Так после хотфикса надо же в дев подтянуть изменения из него, разве нет?

ну дак а если надо только этот чейндж смержить в стейдж, а в дэве есть уже куча другого кода который мержить не надо, как в таком случае поступить?

Видимо, править руками нумерацию и скрипты

хотелось бы это дело как-то автоматизировать)

Ребят, кто как формирует ошибки и определяет на стороне транспортного слоя, какое описание и status code необходимо отдать клиенту? К примеру, формируется ошибка в репозитории, далее передается слою service, который может ее тоже дополнить/изменить. Какие практики есть?

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

cкорее всего заголовки разные. Выводить заголовки из GO + curl -vvv

Так это вы в своей команде должны решить

Ага, мы как то коряво это делаем, хотим выбрать нормальный подход. Подумали сначала что получится errors.Is() и враппать, но увы, такой подход не проверяет вложенные ошибки

{
   "error": {
       "id": null,
       "errors": {
           "name": [
               "has already been taken"
           ]
       },
       "full_messages": [
           "Name has already been taken"
       ]
   }
}


422 отдаёт postman

притом 201 отдаёт норм и всё что нужно делает

сравните заголовки ЗАПРОСА между курлом и go-программой.
при чем вплоть до версии HTTP (может разница в версии и как следствие разные хэндлеры на сервере).