Смотря что вы имеете в виду. Если вы о type erasure в смысле C++
Нет, я про type erasure в смысле дженериков в Java
Если я нигде не пользуюсь конкретным n в типе Vect n Nat, то таскать с собой n в рантайме совершенно не обязательно.
В смысле если мы у нас есть объект с полем, которое называется pole и мы этот объект передаём по значению и путём статического анализа кода мы поняли, что pole не используется внутри функции, то мы можем не делать копию pole при передаче?
"не используйте технологии/процессы бездумно, а спрашивайте себя и команду зачем и почему"
Представьте себе ситуацию - вы не значете, зачем вы используете именно эту технологию и почему процесс выстроен именно так. Ну, то есть спросили и не нашли ответа, который вас бы устроил. Что делать дальше?
Ну как. Процессы называют аналогичными, если они описываются одинаковыми уравнениями. Ну или похожими, если аналогия не точная. Это нужно как раз, для того, чтобы не понимать, как происходит процесс, но иметь возможность его контролировать, за счёт того, что ты понимаешь, как происходит аналогичный процесс
Аналогии для объяснения вредны, потому что создают больше проблем, чем решают Полезны они только для иллюстрации, когда вы кого-то чему-то учите, а не спорите с кем-то.
Я бы даже сказал, что не для иллюстрации, а для того, чтобы человек мог что-то делать, на самом деле не понимая что он делает.
Вы верно понимаете проблему, но у вас плохой аргумент.
Про АЭС это был не аргумент, это была аналогия. Аналогии врут, но мне постоянно советуют использовать их для объяснения. В очередной раз я продемонстрировал, что их лучше не использовать.
В случае ML-инструментов (но не только их) существует проблема того, что мы не знаем, что именно случится, если их использовать.
Хорошее уточнение, да. Если развить аналогию с АЭС, то можно сказать, что когда ты не в курсе какие правила нужно соблюдать, чтобы АЭС была безопасной - лучше её вообще не включать. Но аналогии врут, конечно. То, что написали вы, мне кажется более понятным.
Традиционное замечание: инструменты не опасны, опасны люди которые их применяют со злыми намерениями.
Стандартный ответ от Юдковского. В случае с ИИ опасен инструмент сам по себе. Для того, чтобы он принёс вред, злых намерений не нужно. Как с атомной электростанцией - достаточно не соблюдать технику безопасности и всё кончится плохо. И если с АЭС технику безопасности хотя бы стараются соблюдать, то с ИИ этот вопрос не волнует вообще никого.
Не это? А что вы имеете в виду? Непонятно о чём речь. Непонятно на какой кусок из моего комментария вы возражаете. Я писал, что @BatchSize помогает одновременно порешать проблему декартова произведения и проблему n + 1 . Так оно и есть.
Я же говорю про inner select и CTE
Сложно сказать, что вы имеете в виду. Я сначала думал, что речь о том, чтобы с помощью подзапрос вытащить все элементы коллекции и преобразовать их в jsonb, но дальше вы пишите, что Hibernate умеет делать inner select. Наверное вы имели в виду subselect, но в Hibernate он отвечает за другое. Было бы круто пример какой-нибудь
Hibernate можно постараться приказать делать inner select, только он будет игнорировать указания в ряде случаев (и не упадет с ошибкой)
Наше приложение не могло идентифицировать эту разнообразную чушь и падало. Мы сначала писали кучу обработчиков, но тщетно... вот пришли к такому решению.
Ну по идее надо сделать один обработчик на методе получения данных. Или там данные, которые пришли снаружи, могли привести к ошибке в непредсказуемый момент? Тогда я бы стал логать данные и также сделал общий обработчик, который пишет в логи стектерйс эксепшна.
Игнорировать исключения - неправильно, надо их хотя бы логгировать. Я лично в своём пет проекте пару дней назад словил неприятностей, потому что заигнорил исключения. Казалось, там вооще ничего не могло пойти не так. А надо было логгировать, времени это бы мне сэкономило серьёзно.
Видимо не понравилось оно сообществу. Один хейт в комментариях.
Хейт не из-за того, что ваше решение не понравилось, а из-за того, что вы не использовали стандартные решения. Мне ваша статья понравилась, я её плюсанул. Для меня наличие стандартного решения - не повод не рассказать о велосипеде.
Комментарий у меня ехидный получился, конечно ((( . Примите как дружескую подколку. Как я понял суть вашей статьи в том, как манипулировать процессами с помощью питона, а не в том, как писать идеальный код ))
Может быть если бы вы написали, что можно было решить проблему по другому, но вы выбрали именно свой вариант - минусов было бы меньше. Но и комментариев было бы меньше ))
Должны быть из-за того, что вторая транзакция пытается записать новое значение в поле, которое поменялось после чтения. Но чтобы проблемы были, надо поставить уровень изоляции выше, чем READ_COMMITTED. И, конечно, зависит от используемой СУБД
Ааа, акцент на сеттерах, а геттеры просто были упомянуты за компанию. Я не так понял ))
Ты передал его как аргумент и не можешь быть уверен в его состоянии.
В том числе поэтому мы мапим энтити в ДТО.
JPA требует конструктор без аргументов и не final переменные (hibernate позволяет обойти, но через костыли).
Hibernate позволяет возвращать из запросов ДТО, или можно сразу использовать Spring Projections.
Как только списков становится несколько - оно перестает работать.
Тут надо уточнить, что речь о том, что у пользователя может быть список карт и ещё, допустим, список машин. И тогда у ОРМ будет проблема выбора этого списка одним запросом. Из-за ограничений классического SQL.
И понятно, что сначала надо вытащить пользователей с картами и ещё одним запросом вытащить машины. И точно также всё будет если использовать SQL.
При этом вы в sql можете вернуть список карт как массив или jsonb.
Если использовать такие штуки, как массивы и jsonb для формирования полей в ответе, то можно добиться примерно того же эффекта, что Hibernate производит с помощью @BatchSize . Времени придётся потратить больше, кода написать больше, но да, возможно даст похожие результаты.
Если прямо сразу хранить списки в jsonb, то впринципе при использовании чистого SQL получится, написав больше кода и потратив больше времени, достичь похожих результатов.
Может быть получится выиграть немного производительности или уменьшить количество трафика между БД и приложением. А может и нет, не уверен.
У вас есть транзакция. Большинство операций читающие. Вы создали энтити. Есть 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 вам пришлось бы писать руками. Но надо понимать как им пользоваться, тут никуда не денешься.
куча других исключений может быть, но про них никогда не узнаем, потому они все замалчиваются
Если прочитать статью то создаётся впечателение, что именно этот подход её и родил )). Вот, приведу цитату
Но вот незадача... Вроде бы весь код отлажен, работа приложения стабильна, но в какие‑то моменты замечается, что «бах» и процесс пропал. Ни ошибки в логах, ни сигналов, ничего нет. И как ловить, не очень понятно
Почему же в логах нет ошибок, как же так могло получиться ))
Юдковский ещё не родился, когда другие говорили про риск вымирания из-за ИИ.
Агрументировано, а не как в фильме Терминатор? А кто эти люди? Буду очень благодарен за отсылки?
А Юдковский просто трус.
Ну как. Чтобы понимать, что твоя жизнь скоро кончится и всё равно продолжать что-то делать, нужно много смелости. Равно как и для того, чтобы десятилетия высказывать непопулярное мнение. В чём проявляется его трусость?
В интернете довольно много пояснений. Раньше всех о рисках вымирания из-за ИИ начал рассказывать Юдковский, можно его погуглить. Кстати, по его мнению ядерная война это не так страшно, как ИИ, потому что после ядерной войны ведь кто-то выживет
Нет, я про type erasure в смысле дженериков в Java
В смысле если мы у нас есть объект с полем, которое называется pole и мы этот объект передаём по значению и путём статического анализа кода мы поняли, что pole не используется внутри функции, то мы можем не делать копию pole при передаче?
Задам дурацкий вопрос. Это про type erasure?
Представьте себе ситуацию - вы не значете, зачем вы используете именно эту технологию и почему процесс выстроен именно так. Ну, то есть спросили и не нашли ответа, который вас бы устроил. Что делать дальше?
Ну как. Процессы называют аналогичными, если они описываются одинаковыми уравнениями. Ну или похожими, если аналогия не точная. Это нужно как раз, для того, чтобы не понимать, как происходит процесс, но иметь возможность его контролировать, за счёт того, что ты понимаешь, как происходит аналогичный процесс
Я бы даже сказал, что не для иллюстрации, а для того, чтобы человек мог что-то делать, на самом деле не понимая что он делает.
Про АЭС это был не аргумент, это была аналогия. Аналогии врут, но мне постоянно советуют использовать их для объяснения. В очередной раз я продемонстрировал, что их лучше не использовать.
Хорошее уточнение, да. Если развить аналогию с АЭС, то можно сказать, что когда ты не в курсе какие правила нужно соблюдать, чтобы АЭС была безопасной - лучше её вообще не включать. Но аналогии врут, конечно. То, что написали вы, мне кажется более понятным.
Стандартный ответ от Юдковского. В случае с ИИ опасен инструмент сам по себе. Для того, чтобы он принёс вред, злых намерений не нужно. Как с атомной электростанцией - достаточно не соблюдать технику безопасности и всё кончится плохо. И если с АЭС технику безопасности хотя бы стараются соблюдать, то с ИИ этот вопрос не волнует вообще никого.
Можем, да.
Вот это прямо интересно, может у вас есть ссылки на тесты?
Вы проверяли? Какую СУБД использовали? Может быть есть ссылка на гихаб?
Не это? А что вы имеете в виду? Непонятно о чём речь. Непонятно на какой кусок из моего комментария вы возражаете. Я писал, что @BatchSize помогает одновременно порешать проблему декартова произведения и проблему n + 1 . Так оно и есть.
Сложно сказать, что вы имеете в виду. Я сначала думал, что речь о том, чтобы с помощью подзапрос вытащить все элементы коллекции и преобразовать их в jsonb, но дальше вы пишите, что Hibernate умеет делать inner select. Наверное вы имели в виду subselect, но в Hibernate он отвечает за другое. Было бы круто пример какой-нибудь
Можно пример?
Чтобы использовать select for update с jpa нужно написать
Не то чтобы это сильно отличается по удобству от вставки for update прямо в запрос
Ну по идее надо сделать один обработчик на методе получения данных. Или там данные, которые пришли снаружи, могли привести к ошибке в непредсказуемый момент? Тогда я бы стал логать данные и также сделал общий обработчик, который пишет в логи стектерйс эксепшна.
Игнорировать исключения - неправильно, надо их хотя бы логгировать. Я лично в своём пет проекте пару дней назад словил неприятностей, потому что заигнорил исключения. Казалось, там вооще ничего не могло пойти не так. А надо было логгировать, времени это бы мне сэкономило серьёзно.
Хейт не из-за того, что ваше решение не понравилось, а из-за того, что вы не использовали стандартные решения. Мне ваша статья понравилась, я её плюсанул. Для меня наличие стандартного решения - не повод не рассказать о велосипеде.
Комментарий у меня ехидный получился, конечно ((( . Примите как дружескую подколку. Как я понял суть вашей статьи в том, как манипулировать процессами с помощью питона, а не в том, как писать идеальный код ))
Может быть если бы вы написали, что можно было решить проблему по другому, но вы выбрали именно свой вариант - минусов было бы меньше. Но и комментариев было бы меньше ))
Но вот в рассматриваемом случае похоже именно этого мы и хотим ))
В комментарии ниже вы сами ответили на это замечание )) . Ну и как я написал выше - изоляция должна быть сильнее чем READ_COMMITTED
Да, именно так, Hibernate это умеет ))
Должны быть из-за того, что вторая транзакция пытается записать новое значение в поле, которое поменялось после чтения. Но чтобы проблемы были, надо поставить уровень изоляции выше, чем READ_COMMITTED. И, конечно, зависит от используемой СУБД
Ааа, акцент на сеттерах, а геттеры просто были упомянуты за компанию. Я не так понял ))
В том числе поэтому мы мапим энтити в ДТО.
Hibernate позволяет возвращать из запросов ДТО, или можно сразу использовать Spring Projections.
Тут надо уточнить, что речь о том, что у пользователя может быть список карт и ещё, допустим, список машин. И тогда у ОРМ будет проблема выбора этого списка одним запросом. Из-за ограничений классического SQL.
И понятно, что сначала надо вытащить пользователей с картами и ещё одним запросом вытащить машины. И точно также всё будет если использовать SQL.
Если использовать такие штуки, как массивы и jsonb для формирования полей в ответе, то можно добиться примерно того же эффекта, что Hibernate производит с помощью @BatchSize . Времени придётся потратить больше, кода написать больше, но да, возможно даст похожие результаты.
Если прямо сразу хранить списки в jsonb, то впринципе при использовании чистого SQL получится, написав больше кода и потратив больше времени, достичь похожих результатов.
Может быть получится выиграть немного производительности или уменьшить количество трафика между БД и приложением. А может и нет, не уверен.
Как и в случае с @BatchSize
Update Trx t set t.sum = t.sum + : diff
Можно и так, особенно, если энтити уже всё равно вычитаны.
В смысле что-то, что одновременно меняет сумму в одной транзакции? Так они же специально создаются, чтобы засунуть туда только одно изменение. Может вы про то, что нужно изменять сумму, доступную на счету?
На эту СУБД-транзакцию, да.
Прямо как в JPQL, да.
Мы всегда делаем lazy и используем join fetch или энтити графы или @BatchSize, когда не хотим делать лишних запросов ))
Как абстракция JPA действительно не очень, это скорее набор инструментов, который уже делает то, что в случае использования чистого SQL вам пришлось бы писать руками. Но надо понимать как им пользоваться, тут никуда не денешься.
А JPA то вам чем не угодил?
Как геттеры и сеттеры мешают программисту?
Если прочитать статью то создаётся впечателение, что именно этот подход её и родил )). Вот, приведу цитату
Почему же в логах нет ошибок, как же так могло получиться ))
Агрументировано, а не как в фильме Терминатор? А кто эти люди? Буду очень благодарен за отсылки?
Ну как. Чтобы понимать, что твоя жизнь скоро кончится и всё равно продолжать что-то делать, нужно много смелости. Равно как и для того, чтобы десятилетия высказывать непопулярное мнение. В чём проявляется его трусость?
Но у него есть функция для оценки успешности его действий
Если его выключить, функция выдаст ноль. А вот на это нейросети уже ни разу не наплевать
В интернете довольно много пояснений. Раньше всех о рисках вымирания из-за ИИ начал рассказывать Юдковский, можно его погуглить. Кстати, по его мнению ядерная война это не так страшно, как ИИ, потому что после ядерной войны ведь кто-то выживет