Там еще веселье будет, если нужно много записей вставлять. Hibernate может делать что-то типа кэша ID, так что не бегает за каждым ID в базу. Если такого добиваться вручную, придется немного повозиться.
А еще с batch операциями придется повозиться, кстати.
Всячески могу рекомендовать The Well-Grounded Java Developer, Second Edition, авторы Benjamin Evans, Jason Clark, Martijn Verburg. Там обо всем понемногу, но книжка будет полезна и новичкам, и профикам. Там не только про Java, но и про то, что вокруг. Очень помогает расширить сознание.
Если используете Spring Framework, то там есть аннотация `@Sql`, которая решает сходные задачи. Не пробовали смотреть, как у них сделано? Было бы интересно почитать про преимущества и недостатки :-)
>Какие версии из используемых вами драйверов можно отнести к "старым"?
"Старые" JDBC драйверы - это те, которые не поддерживают JDBC 3. У каждого вендора свои версии, я так понимаю.
>Это относится только к драйверам старых версий или актуально и для драйверов с поддержкой JDBC v.3?
IDENTITY стратегия не позволяет использовать пакетную вставку вне зависимости от версии драйвера.
>Поделитесь, пожалуйста, примерами как можно повторить такую ошибку. Смысл в том, что другой клиент не обязан знать, что вы для генерации ID используете последовательность. Он может создать себе новую - и это приведет к коллизиям
>Как JPA обрабатывает ситуацию с ошибкой дублирования первичного ключа? Exception выкидывает. Ничего особенного здесь нет.
Да, наверное и это тоже. Поэтому делают Project Valhalla, например. И если вас не пугает английский с французским акцентом, есть доклад 2019 года, где рассказывается прям вообще про неочевидные сложности с перемещением объектов из кучи на стек. Мне прямо очень зашло.
Ещё бы сотрудник Oracle про Shenandoah написал :-) А если по теме - надо поискать обзоры. Тут правильно выбрать способ тестирования ещё надо. 1800$ за Specjbb не всем хочется выкладывать, а изобретать свой всеобъемлющий набор тестов долго. Вот, например, есть некоторые тесты всех GC. Давно делались, но, возможно будут полезны.
Пользовался стандартным WYSIWYG редактором хабра, вставлял текст, потом отмечал его как код. Ничего другого тут не предусмотрено, к сожалению. Старый редактор умеет MD разметку, но он что-то не захотел работать с длинным текстом. Поэтому решил попробовать новый редактор и получилось то, что получилось.
With minor modifications to PostgreSQL query plan data structures we can save a pointer to generated machine code and reuse it together with prepared GENERIC plan. But this is not enough as absolute addresses of run-time data structures that we use during code generation change on every query execution. At the run-time the execution control flows from JIT to PostgreSQL functions and vice versa. => Need to update obsolete addresses in generated machine code before it can be used again.
Не простейшим. Понятным. Или хорошо задокументированным. Утрируя: если быстрая сортировка нам сэкономит вагон денег, готовы ли мы пожертвовать пузырьком? Или таки наймем людей, которые смогут читать и поддерживать быструю сортировку?
Что касается производительности — тут рецепты очень сильно зависят от типа вашего приложения, профиля нагрузки и прочих вещей.
Есть некие универсальные подходы, которые можно найти в статьях про Spring/Spring Boot, это все применимо и в Jmix.
А в каждом уникальном приложении свой набор «бутылочных горлышек», которые нужно отдельно выявлять и устранять. Где-то памяти добавить под сессии, где-то кэш добавить, где-то СУБД кластеризовать.
Тут разговор о том, что если у вас один потребитель, который в вашей власти — то это не «классический» API. Документировать его надо не для «внешних» пользователей, а для своих же разработчиков. И менять можно, не очень опасаясь обратной совместимости. Да, можно держать две версии, но потом одну выкинуть без опаски, что клиент сломается.
Мы используем Vaadin 8. Переезд на более новые версии в планах есть, но это не первый приоритет. Для Jmix мы рекомендуем делать приложения с использованием React. У нас есть генераторы для TypeScript SDK и UI, чтобы упростить жизнь разработчикам. Вот тут можно почитать про наши разработки и пройти небольшой QuickStart. И да, в качестве API по умолчанию планируем использовать GraphQL вместо REST.
Но TypeScript SDK останется — это хороший слой абстракции над API Jmix бэкэнда.
Там еще веселье будет, если нужно много записей вставлять. Hibernate может делать что-то типа кэша ID, так что не бегает за каждым ID в базу. Если такого добиваться вручную, придется немного повозиться.
А еще с batch операциями придется повозиться, кстати.
Всячески могу рекомендовать The Well-Grounded Java Developer, Second Edition, авторы Benjamin Evans, Jason Clark, Martijn Verburg. Там обо всем понемногу, но книжка будет полезна и новичкам, и профикам. Там не только про Java, но и про то, что вокруг. Очень помогает расширить сознание.
Если используете Spring Framework, то там есть аннотация `@Sql`, которая решает сходные задачи. Не пробовали смотреть, как у них сделано? Было бы интересно почитать про преимущества и недостатки :-)
Свои результаты я могу нагенерить, это не очень сложно. В тексте статьи я привел ссылку на статью - https://amrutprabhu.medium.com/spring-boot-jpa-bulk-insert-performance-by-100-times-14ec10fa682b - там уже все сделано.
>Какие версии из используемых вами драйверов можно отнести к "старым"?
"Старые" JDBC драйверы - это те, которые не поддерживают JDBC 3. У каждого вендора свои версии, я так понимаю.
>Это относится только к драйверам старых версий или актуально и для драйверов с поддержкой JDBC v.3?
IDENTITY стратегия не позволяет использовать пакетную вставку вне зависимости от версии драйвера.
>Поделитесь, пожалуйста, примерами как можно повторить такую ошибку.
Смысл в том, что другой клиент не обязан знать, что вы для генерации ID используете последовательность. Он может создать себе новую - и это приведет к коллизиям
>Как JPA обрабатывает ситуацию с ошибкой дублирования первичного ключа?
Exception выкидывает. Ничего особенного здесь нет.
В смысле - "встраиваться"? Планируется, что это будет частью JVM. Когда до ума доведут. Вот тут все написано же.
Да, наверное и это тоже. Поэтому делают Project Valhalla, например. И если вас не пугает английский с французским акцентом, есть доклад 2019 года, где рассказывается прям вообще про неочевидные сложности с перемещением объектов из кучи на стек. Мне прямо очень зашло.
Ещё бы сотрудник Oracle про Shenandoah написал :-) А если по теме - надо поискать обзоры. Тут правильно выбрать способ тестирования ещё надо. 1800$ за Specjbb не всем хочется выкладывать, а изобретать свой всеобъемлющий набор тестов долго. Вот, например, есть некоторые тесты всех GC. Давно делались, но, возможно будут полезны.
Вот ответ автора: https://dev.to/xenatisch/comment/1jokg Там много и логично, как мне кажется, объяснено.
Мне кажется, надо пойти в комменты и накомментировать там 🙂 Может, займусь...
А ещё я не очень понимаю, как там мониторинг был настроен. Почему задержки с ответами не были пойман раньше.
Жаль, что автор не написал, какие ещё были сделаны изменения.
А кривые ссылки поправил, да
Пользовался стандартным WYSIWYG редактором хабра, вставлял текст, потом отмечал его как код. Ничего другого тут не предусмотрено, к сожалению. Старый редактор умеет MD разметку, но он что-то не захотел работать с длинным текстом. Поэтому решил попробовать новый редактор и получилось то, что получилось.
Вот тут (правда, всего лишь 2019 год) на 7 слайде говорится, что можно кэшировать вручную: http://ivannikov-ws.org/2019/docs/Buchatskiy.pdf
И дальше интересно:
With minor modifications to PostgreSQL query plan data structures we can save a pointer to generated machine code and reuse it together with prepared GENERIC plan. But this is not enough as absolute addresses of run-time data structures that we use during code generation change on every query execution. At the run-time the execution control flows from JIT to PostgreSQL functions and vice versa. => Need to update obsolete addresses in generated machine code before it can be used again.Конфиг сервер же! :-)
Не простейшим. Понятным. Или хорошо задокументированным. Утрируя: если быстрая сортировка нам сэкономит вагон денег, готовы ли мы пожертвовать пузырьком? Или таки наймем людей, которые смогут читать и поддерживать быструю сортировку?
Есть некие универсальные подходы, которые можно найти в статьях про Spring/Spring Boot, это все применимо и в Jmix.
А в каждом уникальном приложении свой набор «бутылочных горлышек», которые нужно отдельно выявлять и устранять. Где-то памяти добавить под сессии, где-то кэш добавить, где-то СУБД кластеризовать.
Но TypeScript SDK останется — это хороший слой абстракции над API Jmix бэкэнда.