Не совсем. Там получается два разных потока. В одном контекста много. Потом через какое-то время (через пару тройку дней) разработчик входит в другой поток, где он уже забыл контекст и стремится сделать всё как можно более понятным.
Вариантов-то всего три: сравнивать по ссылке, сравнивать по id, сравнивать по всем атрибутам. Почему плох третий — автор написал, теперь сравним первые два варианта.
Правильно сравнивать по Id, но добавить условие, что если id ==null, то equals выдаст false. Ну и плюс вернуть константу в hashCode конечно
Проще не создавать никакого поля и использовать equals и hashCode по умолчанию.
Такая позиция существует, но тогда получается, что будут проблемы с пониманием, что две энтити у которых равен id относятся к одной и той же строке в БД
И все равно так не делайте. Это выстрелит через непонятное время.
Вот если написать в hashCode не константу, то да, выстрелит. Не сразу, но обязательно будут плавающие баги.
Ваши хешмапы превратились в тримапы. logn это не очень много, но все равно легко можно написать код который думая что там o(1) внезапно начнет тормозить на пустом месте.
Для этого не надо использовать энтити как ключи в хешмапе. А когда используешь коллекции типа HashSet, надо помнить, что нельзя класть туда много элементов. Но вообще надо просто помнить, что надо делать связи OneToMany в которых много элементов
За исключением случая, когда речь идёт о hashCode в классе, помечнном аннотацией Entity.
Это бессмысленно,
В случае с Entity это крайне осмысленно, потому что equals должен быть завязан на Id и Entity у которых Id == null должны быть не равны друг другу, чтобы можно было сложить их в Set
поскольку не просто ухудшает производительность хеш-таблиц, но сводит их к массиву.
Не к массиву, а к дереву, но да, сводит. Поэтому Entity не надо делать ключами в HashMap. Что касается коллекций типа Set — когда речь идёт об Entity, там в любом случае нельзя держать много элементов, так что ничего страшного не случится.
Но если вам достаточно массива, почему бы не использовать ArrayList вместо хеш-таблицы?
Обычно так и делают. Но даже в этом случае надо сделать так, чтобы arrayList.contains работал корректно, когда ему отдают Entity с id равным null
Лет пять назад у меня на Хабре был точно такой же диалог ))). Тогда один из участников сказал, что сначала он пишет код в потоке, а потом в потоке же его рефакторит. Чтобы код стал максимально простым и понятным.
Когда говорят, что у людей есть инстинкты, не имеют в виду определение слова инстинкт из учебника биологии. Имеют в виду, что человек хочет жить и хочет чтобы его уважали и вот это всё.
И вот баш тут плох уже как язык, потому что на нём сложные вещи опасно писать.
Я бы сказал сложно, долго и отсутствует инструментарий для разработки.
Наверное, с точки зрения человека, который хорошо владеет башем — баш это просто супер. По крайней мере я такую точку зрения встречаю регулярно.
Но мне, всё что не просто склеивание утилит в пайплайн, приходится гуглить. Но даже если бы я не гуглил, я всё не могу написать юнит тесты на логику, а это приводит меня в перманентно нервозное состояние. Логика это, кстати всё, что не склейка. if, test [, || вот это всё. Я уже дошёл до такого состояния, что меня триггерит чуть ли не проверка любого условия.
Джавой я могу так же склеить утилиты в пайплайн, это несложно, плюс я могу описать логику, плюс я могу написать юнит тесты, плюс я могу сделать всё, что угодно, не зависая часами в гугле.
У скриптов есть преимущество, что можно поправить скрипт "на месте", но во-первых с джавой сейчас так тоже можно, а во вторых я годами занимаюсь тем, что пишу код, любое изменение в котором тестируется, проходит через пайплайн и запускается где надо и когда надо. Любой разработчик сейчас это умеет, проблем нет.
Как я вижу, чтобы заменить баш, на языках общего назначения пилят всякие DSL типа ansible и иже с ней. Но если принять тот факт, что назначение шелл скриптов — склеивать утилиты в пайплайн, то для того, чтобы заменить баш на джаву, достаточно просто сделать библиотеку, которая немного упростит комбинирование сторонних утилит. И всё. Непонятно почему до сих пор никто не занялся.
Для тех, кому любопытно, что тестируется и как замеряли.
Сделано веб приложение, которое вытаскивает все записи из таблицы (записей 12, но коду запрещено об этом заранее знать) и кладёт в лист. Потом в лист кладут ещё один объект и дальше лист сортируется по одному из полей. Сортировки в запросе заранее нет.
Далее этот лист скармливается шаблонизатору, который делает из объектов html таблицу из 13 строк.
Вот на этом сценации spring обрабатывает 23 тысячи запросов в секунду, а aspcore 105 тысяч. Спринг никто не тюнил, единственное, что расширили пул коннекшнов к БД до 2 * количество ядер. aspcore наверное тоже никто не тюнил, но специально это не оговорено.
Что интересно, если не ограничивать тесты спрингом, то джава работает быстрее, чем любой вариант C#, поэтому можно предположить, что дело действительно в каком-то из компонентов спринга.
Также, если измерять сценарий в котором каждый http запрос приводит к появлению нескольких запросов к БД, spring быстрее чем aspcore раза в 2, а если измерять только сериализацию в json, то aspcore быстрее spring раз в 10.
Ну вот с какого перепугу, простите, PG вдруг стал пользовательским приложением?
Думаю нет большой разницы как это назвать. Постгрес это программа, которую пользователь может запустить или остановить.
Почему он должен лежать в «хомяке» пользователя?
А какие причины класть его куда-то ещё? Положить его в home имеет смысл хотя бы для того, чтобы можно было сразу использовать его после переустановки. Или снести просто удалив директорию.
Как делить один порт между постгресами разных пользователей?
Мне кажется это один из основных посылов статьи. Статья про линукс на десктопе, а на десктопе де факто не работает несколько пользователей одновременно. Поэтому этой проблемы совсем нет.
Кто вам мешает по надобности запустить отдельный постгрес на отдельном порту от отдельного пользователя со всеми настройками и var'ом внутри хомяка? Кто заставляет ставить общесистемный постгрес?
Ну как кто? Менеджер пакетов в линуксе. Хочешь держать постгрес в своей директории — делай всё руками.
Кто запретил докер?
Ещё один сервис, который не конфигурируется в home. Его никто не запрещал, даже наоборот, его сделали, чтобы решить проблему с постгресом, которую вы не считаете заслуживающей внимания.
Зачем вообще отдельный постгрес на пользователя нужен на домашней машинке
Для разработки. Или штуки разные пробовать не засоряя систему. И так далее.
Очень много странных заведомо риторических вопросов, порождаемых неверной классификацией постгреса в качестве пользовательского приложения.
Какая разница, как его классифицировать? Сценарии использования какие были такие и остались. Хранить конфигурацию так, чтобы можно было править её не от рута, как было удобно, так и осталось.
Если вы заранее об этом знаете, то нет проблемы перенести нужные настройки.
Да, только люди вокруг зачем-то твердят, что для того, чтобы все настройки сохранились достаточно вынести home в отдельный раздел. А это, как быстро выясняется, не так.
Они и не должны.
Не должны. В статье собственно и написано, что на декстопе всё программное обеспечение принадлежит одному пользователю, и настройки логично было бы искать в директории пользователя, но линукс пользуется другой логикой.
С чего бы вдруг?
Для того, чтобы совет выносить home в отдельный раздел действительно помогал сохранить конфигурацию.
Если их не переносить, у меня система не будет работать. И я тут не один такой уникальный.
Так задумано.
Ну да, так задумано. Это одна из проблем линукса на десктопе, что так задумано.
В 99% случаев сохранение настроек программ и ДЕ через монтирование хомяка работает.
Наверное. Но вот мне нужно сохранить конфигурацию докера, systemd, postgresql, xorg и так далее. Никто из них не хранит конфигурацию в home. Я раньше думал, что standalone cборки это для windows актуально, но чем дальше, тем больше у меня впечатлени, что это актуально и для линуксов. Может быть за исключением NixOs или Guix
Проблема этого километра текста в том, что это километр ниочемного текста.
Мне много раз разные люди говорили, что нужно выделять для home отдельный раздел, потому что тогда при поломке можно просто поставить линукс заново и примонтировать к нему старый home. И тогда сохранятся все настройки. На самом деле не сохранятся. Как минимум вот этот момент автор отразил неплохо.
Не совсем. Там получается два разных потока. В одном контекста много. Потом через какое-то время (через пару тройку дней) разработчик входит в другой поток, где он уже забыл контекст и стремится сделать всё как можно более понятным.
Конкретно в энтити — есть необходимость безопасно добавлять и в Set.
Да, добавили в сет пока id == null, потом записали в БД и id сгенерировались и при этом сет должен работать корректно.
Правильно сравнивать по Id, но добавить условие, что если id ==null, то equals выдаст false. Ну и плюс вернуть константу в hashCode конечно
HashMap невозможно превратить в ArrayList. В лучшем случае будет дерево.
Такая позиция существует, но тогда получается, что будут проблемы с пониманием, что две энтити у которых равен id относятся к одной и той же строке в БД
Вот если написать в hashCode не константу, то да, выстрелит. Не сразу, но обязательно будут плавающие баги.
Для этого не надо использовать энтити как ключи в хешмапе. А когда используешь коллекции типа HashSet, надо помнить, что нельзя класть туда много элементов. Но вообще надо просто помнить, что надо делать связи OneToMany в которых много элементов
За исключением случая, когда речь идёт о hashCode в классе, помечнном аннотацией Entity.
В случае с Entity это крайне осмысленно, потому что equals должен быть завязан на Id и Entity у которых Id == null должны быть не равны друг другу, чтобы можно было сложить их в Set
Не к массиву, а к дереву, но да, сводит. Поэтому Entity не надо делать ключами в HashMap. Что касается коллекций типа Set — когда речь идёт об Entity, там в любом случае нельзя держать много элементов, так что ничего страшного не случится.
Обычно так и делают. Но даже в этом случае надо сделать так, чтобы arrayList.contains работал корректно, когда ему отдают Entity с id равным null
Лет пять назад у меня на Хабре был точно такой же диалог ))). Тогда один из участников сказал, что сначала он пишет код в потоке, а потом в потоке же его рефакторит. Чтобы код стал максимально простым и понятным.
Это неправда ))). Сепульки — наименование биологческого таксона )))
А почему для 64-битных систем это не важно?
У джаваскриптового движка в файрфоксе разве не трассирующий gc?
Когда говорят, что у людей есть инстинкты, не имеют в виду определение слова инстинкт из учебника биологии. Имеют в виду, что человек хочет жить и хочет чтобы его уважали и вот это всё.
Я бы сказал сложно, долго и отсутствует инструментарий для разработки.
Наверное, с точки зрения человека, который хорошо владеет башем — баш это просто супер. По крайней мере я такую точку зрения встречаю регулярно.
Но мне, всё что не просто склеивание утилит в пайплайн, приходится гуглить. Но даже если бы я не гуглил, я всё не могу написать юнит тесты на логику, а это приводит меня в перманентно нервозное состояние. Логика это, кстати всё, что не склейка. if, test [, || вот это всё. Я уже дошёл до такого состояния, что меня триггерит чуть ли не проверка любого условия.
Джавой я могу так же склеить утилиты в пайплайн, это несложно, плюс я могу описать логику, плюс я могу написать юнит тесты, плюс я могу сделать всё, что угодно, не зависая часами в гугле.
У скриптов есть преимущество, что можно поправить скрипт "на месте", но во-первых с джавой сейчас так тоже можно, а во вторых я годами занимаюсь тем, что пишу код, любое изменение в котором тестируется, проходит через пайплайн и запускается где надо и когда надо. Любой разработчик сейчас это умеет, проблем нет.
Как я вижу, чтобы заменить баш, на языках общего назначения пилят всякие DSL типа ansible и иже с ней. Но если принять тот факт, что назначение шелл скриптов — склеивать утилиты в пайплайн, то для того, чтобы заменить баш на джаву, достаточно просто сделать библиотеку, которая немного упростит комбинирование сторонних утилит. И всё. Непонятно почему до сих пор никто не занялся.
Каждый раз, как я вижу пайплайн на баше, мне хочется собрать пайплайн на джаве )). Я прямо убеждён, что получится лучше
Отличный пример, спасибо!
Для тех, кому любопытно, что тестируется и как замеряли.
Сделано веб приложение, которое вытаскивает все записи из таблицы (записей 12, но коду запрещено об этом заранее знать) и кладёт в лист. Потом в лист кладут ещё один объект и дальше лист сортируется по одному из полей. Сортировки в запросе заранее нет.
Далее этот лист скармливается шаблонизатору, который делает из объектов html таблицу из 13 строк.
Вот на этом сценации spring обрабатывает 23 тысячи запросов в секунду, а aspcore 105 тысяч. Спринг никто не тюнил, единственное, что расширили пул коннекшнов к БД до 2 * количество ядер. aspcore наверное тоже никто не тюнил, но специально это не оговорено.
Что интересно, если не ограничивать тесты спрингом, то джава работает быстрее, чем любой вариант C#, поэтому можно предположить, что дело действительно в каком-то из компонентов спринга.
Также, если измерять сценарий в котором каждый http запрос приводит к появлению нескольких запросов к БД, spring быстрее чем aspcore раза в 2, а если измерять только сериализацию в json, то aspcore быстрее spring раз в 10.
Прикольно! А как меряли?
Поделитесь линком на замеры?
Думаю нет большой разницы как это назвать. Постгрес это программа, которую пользователь может запустить или остановить.
А какие причины класть его куда-то ещё? Положить его в home имеет смысл хотя бы для того, чтобы можно было сразу использовать его после переустановки. Или снести просто удалив директорию.
Мне кажется это один из основных посылов статьи. Статья про линукс на десктопе, а на десктопе де факто не работает несколько пользователей одновременно. Поэтому этой проблемы совсем нет.
Ну как кто? Менеджер пакетов в линуксе. Хочешь держать постгрес в своей директории — делай всё руками.
Ещё один сервис, который не конфигурируется в home. Его никто не запрещал, даже наоборот, его сделали, чтобы решить проблему с постгресом, которую вы не считаете заслуживающей внимания.
Для разработки. Или штуки разные пробовать не засоряя систему. И так далее.
Какая разница, как его классифицировать? Сценарии использования какие были такие и остались. Хранить конфигурацию так, чтобы можно было править её не от рута, как было удобно, так и осталось.
Да, только люди вокруг зачем-то твердят, что для того, чтобы все настройки сохранились достаточно вынести home в отдельный раздел. А это, как быстро выясняется, не так.
Не должны. В статье собственно и написано, что на декстопе всё программное обеспечение принадлежит одному пользователю, и настройки логично было бы искать в директории пользователя, но линукс пользуется другой логикой.
Для того, чтобы совет выносить home в отдельный раздел действительно помогал сохранить конфигурацию.
Если их не переносить, у меня система не будет работать. И я тут не один такой уникальный.
Ну да, так задумано. Это одна из проблем линукса на десктопе, что так задумано.
Наверное. Но вот мне нужно сохранить конфигурацию докера, systemd, postgresql, xorg и так далее. Никто из них не хранит конфигурацию в home. Я раньше думал, что standalone cборки это для windows актуально, но чем дальше, тем больше у меня впечатлени, что это актуально и для линуксов. Может быть за исключением NixOs или Guix
Мне много раз разные люди говорили, что нужно выделять для home отдельный раздел, потому что тогда при поломке можно просто поставить линукс заново и примонтировать к нему старый home. И тогда сохранятся все настройки. На самом деле не сохранятся. Как минимум вот этот момент автор отразил неплохо.