Комментарии 32
И при чем тут спринг?
Я - разработчик на этом стеке.
Есть момент с hibernate
Spring jpa позволяет делать очень многое без знания sql, в итоге разрабы не знают даже этого минимума, к сожалению
А как они не знают минимум и работают, еще и многие подолгу. Может это не минимум тогда?
Минимум слово относительное, вопрос в другом: какие решения выходят когда разраб не знает ряда вещей
Если выходят и никто не жалуются, то думаю рабочие )
Это точно и даже хорошо.
Суть в том, что не любой бизнес даёт время на разбор таких моментов. Поэтому многие идут по принципу меньшего сопротивления. Из за этого многие избегают сложностей и у них нет возможности углубляться в проблематику. На этом фоне многие знают как обойти проблемы, но сути самой проблемы не знают. Отсюда поверхностные знания даже за 20 лет работы.
Но полезность таких статей как ваша, непосредственно есть. Так как она позволяет проблемам всплывать и позволяет быстрее разбираться в них.
Ну, а про связки PgBouncer+Hiber это вообще не паханное поле и редко кем используется.
Согласен. Тут я хотел накатать статью про это, но боюсь будет холиварной.
Суть моих заметок помимо того, чтобы дать какие-то достаточно простые вещи, но и триггернуть людей.
Недавно общались с Александром из одного банка и пришли к выводу, что благодоря отношению коллег, руководства и т.д. из разарботки вымываются основопологающие принципы без которых разработка начинает быть не разработкой (это его умозаключение и я с ним согласен).
Ну если не знать sql, то нет смыла заикаться про план запроса, джойны и вообще вот это все выше. Да ладно, не придираюсь, думал может часть текста не сохранилась или продолжение предполагалось)
Нет. Это фарш, телёнка не успел собрать, начинали расхабривать опять.
Пишите еще, полезно все равно
Вопрос в названии. Изначально я писал статью под названием: колходный DBA, типа когда у тебя недоступны DBA и приходиться самому им становиться отчасти, но когда накидал фарш получилось что это не совсем про DBA, а скорее какой-то непонятный мне сбор... Времени слепить из фарша теленка не было, так как мою статью про интервью начали минусть и прилетело в карму, т.е. не было времени все это пересобрать и поразмыслить.
Потому было бы круто, если были бы предложения.
В том числе думал ( и подсказывал коллега) подкинуть сюда еще пару вещей: ltree и windowed функции, но как есть.
Я тоже не понял. Потому как название должности в парадигме автора следует писать так: Spring PostgreSQL java backend разработчик. Свою должность даже представить не могу.
Нужно другое название заметик. Поможете? Буду признателен.
Я понял месс с названием, но один фиг оставлю его таким.
Для начинающих очень полезно.
В статье есть деструктивные примеры, которые лучше не применять на практике. В частности, "проверь свой запрос".
Всё, что вы делаете в БД, остаётся в БД и влияет на её прямым образом.
Нельзя просто так начать транзакцию, откатить ее и сделать вид, что ничего не было. База по-честному будет выполнять ваш запрос, используя backend процесс, потребляя CPU/диск и генерируя WAL.
Бездумно используя подход с begin/rollback, можно выстрелить себе в ногу и на время положить кластер БД.
Могу Ваше замечение про мусор использовать для дополнения в заметке?
Можете, пожалуйста, указать на проблемные моменты в заметке?
И да, верно понимаю, как Вы предлагаете проверить мутационный запрос на стейдже допустим?
Я предпочитаю проверять интеграционным тестом (с Testcontainers, например). Потом на тестовом стенде, который не жалко, и который в случае чего можно перераскатить с нуля.
Комментарий был больше про то, что "безопасные", на первый взгляд, примеры и решения могут на самом деле таить в себе огромный риск, если не понимать, что происходит под капотом.
Согласен. Тут главный момент: наличие субреальных данных, так как бывает, что разраб запихивает какой-то убер апдейт и потом, ну Вы поняли.
Т.е. есть возможность проверить на суб реальных данных (стейдж), но не знают о такой возможности.
Ну и конечно же кто-то пойдет в прод и будет там проверять.... но если у начинающего разраба есть доступ в прод, то это уже опасно изначально)))
Спасибо Вам еще раз за подсвеченное мной упущение!
не совсем понятно, почему про explicit локи написано "этот механизм лучше не использовать совсем".
это стандартный механизм работы с блокировками в Postgres. Им очень даже можно пользоваться, когда нужно.
Как и любым другим инструментом, блокировками нужно уметь пользоваться.
Про устройство блокировок в Postgres и работу с ними есть прекрасный цикл статей @erogov(начиная с этой: https://habr.com/ru/company/postgrespro/blog/462877/)
Блокировки в принципе зло, так как есть оптимистические. Да, без эксплисит можно юзать, но потом начинает проявляется кучка неочевидностей, взаимных блокировок, дедлоков и прочего с чем потом разобраться бывает сложно.
Учитывая, что начинающие разработчики узнают о таком механизме, то может быть искушение его попробовать, потому такое предупреждение.
В моей практике получалось так, что можно было выбрасывать эксплисит локи в 80%.
Кстати, спасибо за линк, очень крутые наработки!
А какое ограничение по глубине в рекурсивных запросах?
Набор практик по работе с Postgresql глазами Spring java backend разработчика