Pull to refresh
35
0
Илья Сазонов @poxvuibr

Software developer

Send message

Ошибка будет на Repeatable Read и выше. Но обычно это не то, чего мы хотим от приложения.

Но вот в рассматриваемом случае похоже именно этого мы и хотим ))

так транзакция прочитала commited (старое) значение. У нее нет проблем. Откуда бд знать что вы хотите сделать.

В комментарии ниже вы сами ответили на это замечание )) . Ну и как я написал выше - изоляция должна быть сильнее чем READ_COMMITTED

Для падения необходимо оптимистичные блокировки использовать на уровне ОРМ/руками.

Да, именно так, Hibernate это умеет ))

нет, откуда?

Должны быть из-за того, что вторая транзакция пытается записать новое значение в поле, которое поменялось после чтения. Но чтобы проблемы были, надо поставить уровень изоляции выше, чем READ_COMMITTED. И, конечно, зависит от используемой СУБД

Если есть сеттеры - обьект мутабельный.

Ааа, акцент на сеттерах, а геттеры просто были упомянуты за компанию. Я не так понял ))

Ты передал его как аргумент и не можешь быть уверен в его состоянии.

В том числе поэтому мы мапим энтити в ДТО.

JPA требует конструктор без аргументов и не final переменные (hibernate позволяет обойти, но через костыли).

Hibernate позволяет возвращать из запросов ДТО, или можно сразу использовать Spring Projections.

Как только списков становится несколько - оно перестает работать.

Тут надо уточнить, что речь о том, что у пользователя может быть список карт и ещё, допустим, список машин. И тогда у ОРМ будет проблема выбора этого списка одним запросом. Из-за ограничений классического SQL.

И понятно, что сначала надо вытащить пользователей с картами и ещё одним запросом вытащить машины. И точно также всё будет если использовать SQL.

При этом вы в sql можете вернуть список карт как массив или jsonb.

Если использовать такие штуки, как массивы и jsonb для формирования полей в ответе, то можно добиться примерно того же эффекта, что Hibernate производит с помощью @BatchSize . Времени придётся потратить больше, кода написать больше, но да, возможно даст похожие результаты.

Если прямо сразу хранить списки в jsonb, то впринципе при использовании чистого SQL получится, написав больше кода и потратив больше времени, достичь похожих результатов.

Может быть получится выиграть немного производительности или уменьшить количество трафика между БД и приложением. А может и нет, не уверен.

Избегая n+1 проблемы, кстати.

Как и в случае с @BatchSize

У вас есть транзакция. Большинство операций читающие. Вы создали энтити. Есть 1 операция, где надо изменить сумму. Как вы это реализуете?

Update Trx t set t.sum = t.sum + : diff

JPA подталкивает вас не думать об этом, сделать trx.setSum(trx.getSum()+diff)

Можно и так, особенно, если энтити уже всё равно вычитаны.

Только вот у нас есть параллельные транзакции?

В смысле что-то, что одновременно меняет сумму в одной транзакции? Так они же специально создаются, чтобы засунуть туда только одно изменение. Может вы про то, что нужно изменять сумму, доступную на счету?

Вы повесите select for update на всю энтити?

На эту СУБД-транзакцию, да.

При это м sql вам даже не надо читать обьект, просто update trx t set sum=t.sum+:diff.

Прямо как в JPQL, да.

Вы или делаете lazy, теряя перформанс на лишний запрос, или получаете список там, где могли этого избежать.

Мы всегда делаем lazy и используем join fetch или энтити графы или @BatchSize, когда не хотим делать лишних запросов ))

Что это за абстракция такая, которая течет не начав работать?

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

а также ужасный JPA

А JPA то вам чем не угодил?

и практика использовать геттеры-сеттеры

Как геттеры и сеттеры мешают программисту?

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

Если прочитать статью то создаётся впечателение, что именно этот подход её и родил )). Вот, приведу цитату

Но вот незадача... Вроде бы весь код отлажен, работа приложения стабильна, но в какие‑то моменты замечается, что «бах» и процесс пропал. Ни ошибки в логах, ни сигналов, ничего нет. И как ловить, не очень понятно

Почему же в логах нет ошибок, как же так могло получиться ))

Юдковский ещё не родился, когда другие говорили про риск вымирания из-за ИИ.

Агрументировано, а не как в фильме Терминатор? А кто эти люди? Буду очень благодарен за отсылки?

А Юдковский просто трус.

Ну как. Чтобы понимать, что твоя жизнь скоро кончится и всё равно продолжать что-то делать, нужно много смелости. Равно как и для того, чтобы десятилетия высказывать непопулярное мнение. В чём проявляется его трусость?

У ИИ нет инстинкта самосохранения.

Но у него есть функция для оценки успешности его действий

Ему глубоко плевать если его выключат опять.

Если его выключить, функция выдаст ноль. А вот на это нейросети уже ни разу не наплевать

В интернете довольно много пояснений. Раньше всех о рисках вымирания из-за ИИ начал рассказывать Юдковский, можно его погуглить. Кстати, по его мнению ядерная война это не так страшно, как ИИ, потому что после ядерной войны ведь кто-то выживет

Нет, там это два разных вопроса. В вопросе про данные из таблицы нет никакого хеширования

Вот было бы круто, если бы кто-то написал не о том, что нужно использовать все коды возврата, а рассказал бы зачем это надо делать )) . И в каких случаях какие коды использовать. Я бы сказал спасибо даже за статью в которой рассказывается в каких случаях надо вернуть 404. За статью, полностью посвящённую только одному этому http коду.

Я чего-то не понимаю. Когда мы алгоритм хеширования выбираем, ГПТ не хочет повышенного внимания, а когда данные из таблицы возвращаем, то вообще никаких проблем. Он какой-то странный

И одновременно быть чудовищно, невообразимо тупым --- чтоб настаивать на выполнении нелепой задачи.

Так можно договориться и до того, что вас не может существовать. Потому что вы вроде как обладаете высоким интеллектуальным потенциало и гибкостью разума, но настаиваете на выполнении такой нелепой задачи, как создание успешных публикаций на Хабре. И это вместо того, чтобы заниматься такой важной и нужной вещью, как максимизация скрепок.

Почти месяц прошёл, а ничего не исправлено. Технический специалист не оставил бы всё вот так. Аккаунт активен, с него публикуются статьи. Вывод очевиден - Сергея Шайкина уговорили отдать аккаунт какому-то копирайтеру, который пишет статьи как может. Если я когда-нибудь встречусь с настоящим Сергеем, я ему обязательно расскажу чего тут публикуют от его имени, ему было бы неплохо об этом знать

Вам виднее

Да, нам виднее.

Хотя на самом деле в случае этой конкретной статьи есть несколько вариантов.

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

Поэтому возможно статью сгенерировал ИИ, но автор не может её поправить, потому что не понимает предметной области статьи.

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

Есть ещё вариант, что автор пишет статьи сам, но не понимает о чём они. Но даже это не могло привести к появлению в статье отрывка типа пассажа о библиотеках. Разве что только эта строчка - результат автоматического перевода. Но тогда кто-то должен был написать такую статью на другом языке, а кто мог такое сделать - непонятно.

Может быть это такой социальный эксперимент?

И я тут говорю об авторе в третьем лице, хотя отвечаю на его комментарий. Это потому что я не уверен, что за аккаунтом какой-то один человек. Может быть аккаунт кому-то передали или что-то такое происходит. Потому что в профиле написано, что автор обожает тестировать бекенд. Такой человек, наверное, не смог бы не поправить косяки.

Но, автор, если вы действительно написали эту статью, то расскажите, что случилось!

Почему она такая? Почему вы не внесли правки?

Что выхотели сказать, когда назвали Maven фреймворком, а Selenium c Selenide библиотеками?

Как в список Java библиотек попал Selenoid, написанный на Go?

Какое значение вы хотели вложить в отрывок про библиотеки, процитированный мной в предыдущем коментарии?

Если это не социальный эксперимент, то как это могло случиться?

Если коротко, то человек не мог написать вот такое.

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

Текст чем-то сгенерировали и даже не вычитали.

Сомневаюсь что разработчики СУБД сами тестируют.

Я правильно понимаю, что вы сомневатесь, что разработчики СУБД тестируют корректность реализации SQL в той СУБД, которую они разрабатывают?

Для этого существуют тестеры с совсем другой зарплатой.

А эти тестеры работают в той компании, которая разрабатывает СУБД?

На самом деле вступления не совсем удачное.

Тогда имеет смысл поправить текст

Статья о том как тестировать базы данных как сервис на примере MariaDB.

Ну вы где-нибудь видели, чтобы кто-то вот так тестировал базу данных как сервис? Если видели, то не могли бы вы описать, что это за компания, какого рода услуги она предоставляет, как использует такие тесты? Я не против, если вы эту компанию выдумаете, но хотелось бы понять, чем она может заниматься, что там нужны такие тесты.

Но это так же применимо и к другим типам баз данных.

Возможно в других базах данных тоже есть дебаг режим, в котором есть тулинг для вот таких тестов. Но кто, кроме разработчиков этих СУБД будет эти тесты запускать?

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

На что протестировать? На корректность реализации SQL? Такие тесты как правило делают сами разработчики СУБД. А если нужно протестировать подойдёт ли эта база данных для вашего приложения, то это делается совсем по другому.

Я всё пытаюсь понять, какое отношение статья имеет к тестированию бекенда и у меня не выходит.

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

Я вообще не могу представить, где в разработке веб сервисов могут встретиться такие тесты. Вы такое видели?

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

Да тут впринципе со статьёй что-то не так. Сначала написано, что будем искать книги, у которых название начинается с какой-то строки, но в коде ничего такого нет. Энтити с книгами и авторами нет, есть какой-то Workspace. Ну и так далее

Information

Rating
4,898-th
Works in
Date of birth
Registered
Activity