powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Правильный подход с реализацией equals/hashCode ?
18 сообщений из 43, страница 2 из 2
Правильный подход с реализацией equals/hashCode ?
    #38803847
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonАвтор пишет что до момента вставки в БД, id еще не определён.

Это от скудности опыта. Я не знаю какой стек технологий он использует
но в Oracle, генерация суррогатных ПК никак не связана со вставкой.

Вы получаете его значение как Sequence_name.nextval и оно 100% уникально
в рамках системы. Дальше - используете его как хотите. Вставляйте сразу ID,
а потом обновляйте филды или вставляйте вместе. Вобщем либерально.

Вам конечно виднее про мой опыт. В логике системы я создаю множество объектов. И далеко не факт, что эти объекты будут в итоге сохранены в БД. И дёргать БД только для того, чтобы получить id объекта, который возможно не будет сохранён в БД - на мой взгляд странно. Да, объект получит свой id из sequence в момент вставки в БД.

maytonА про хибернейты меньше надо читать. Они только портят общее понимание
как работает БД.

Это из разряда - "..., но осуждаю"?

Не имеет значения какой стэк в моём случае используется. Будь то голый JDBC или одна из ряда ORM. К вопросу это не имеет отношения.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803851
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevmaytonТиппичный лог
Код: plsql
1.
SQL> create myFuckenLogTable(ts TIMESTAMP,eventType NUMBER,event VARCHAR2(255)) [interval partitioning options by ts ];



В многопользовательской системе, хорошо бы как-то по user'ам / или на крайняк процессам-сессиям разделять

А то если два пользователя одновременно работать будет - такая помойка получится )))
Да это просто пример. Семантика event VARCHAR2(255) может быть вполне осмысленная. И с юзером и с сессией.

У меня есть свой log4j appender. С кольцевым буфером. С опциями расширенных Layouts. Там это всё есть.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803852
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не претендую на истинность в последней инстанции, но у нас на проекте Hiubernate сразу же ID выдавал (вроде через newEntity() создавали).

Правда там все было сложно: Hibernate -> Cobol -> Oracle. В детали реализации старались не лезть, что бы не пугаться.

1. Использовать id. Плохо тем, что до момента вставки в БД id ещё не определён.

AFAIK
Например MS Visual FoxPro при оптимистической блокировке, до момента вставки выдает ROWNUM -1, -2, -3 etc... В момент физического Insert'а ROWNUM становится реальным.

В Oracle Forms мы просто запрашивали очередной ID из сиквенса. Сиквенс большой, его не жалко.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803855
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У базы и файла есть принципиальная разница: данные в упорядочены в порядке поступления Для СУБД это не гарантируется.
Соответственно, если чтение логов требует или предполагает знание порядка поступления записей от приложения, то этот порядок должен обеспечиваться суррогатным первичным ключом.
Механизм генерации такого ключа - последовательности.

P.S. Да, "почти одновременные" log(message) из разных процессов могут попасть в файл протокола в более-менее произвольном порядке. Но после записи - этот порядок будет фиксирован.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803857
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonА точность TIMESTAMP задаётся до 10 знаков после запятой. Как вы понимаете трудно создать процесс который
генерит события дважды за 0.0000000001 s.

Вопрос добавления доп. ключа типа sequence к timestamp для меня остаётся открытым. Я не знаю зачем мне нужен
и какую пользу я получаю от этого.

Вобщем это лучше обсудить с Ораклоидами . Накидают больше советов чем я.
Как многие понимают, создать процесс который генерит множество событий за 0.0000000001 s. - очень легко. Про точность TIMESTAMP тоже очень спорно, зависит от конкретной платформы.

Ещё небольшое уточнение - почему Вы всегда упоминаете здесь Oracle? В посте ни слова про него не было. От богатства опыта?
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803870
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonНе забывайте что речь идёт о самом банальном логе. Мы не фиксируем туда bulk-операции
в порядке поступления ВСЕХ данных. Мы не агрегируем логи с облака серверов. Мы не накапливаем
гигабитный трафик пакетов.

Мы просто фиксируем чортовы события. Юзер залогонился. Юзер оплатил счёт. Вышел. Как в 99.9% системах.

Если у вас действительно есть постановка в которой происходит тот ужас который я перечислил то
это не является логом. И к нему моя схема - неприменима.

Вот как-то в таком вот аспекте.
С таким "банальным" подходом можно и вообще ничего не логгировать. Сколько приходилось анализировать логи в production, когда система реально работает и множество пользователей чего-то делают и делается ещё много чего между разными системами и много чего делается асинхронно - всегда время записи в лог, порядок записи - были критически важны. И всегда было важно, чтобы время было синхронизировано на всех серверах системы.

А теперь оказывается это и не лог вовсе в Вашем понимании.
Чувствуется большой опыт.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803874
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junixarЕщё небольшое уточнение - почему Вы всегда упоминаете здесь Oracle? В посте ни слова про него не было. От богатства опыта?
Это верно. Мои примеры особенно с лог-табличкой с опциями interval partitioning (специально не писал
ибо многобукв) - Oracle-технологичны.

Однако если кто-то приведёт другой пример в плоскости Java - буду рад.

Меня справедливо обвиняют в оффтопике. Забыл что тема - Java - сорри.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803878
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junixar...
maytonА про хибернейты меньше надо читать. Они только портят общее понимание
как работает БД.

Это из разряда - "..., но осуждаю"?

Не имеет значения какой стэк в моём случае используется. Будь то голый JDBC или одна из ряда ORM. К вопросу это не имеет отношения.
Мне кажется тут mayton прав

У Вас получается все скомкано в одну кучу. И объекты, и база. Отсюда и проблемы.

Термин "время жизни объекта" он же тоже не абсолютный, а от контекста зависит. Добавили объект в БД, старый грохнули, новый создали ))) Вот Вам и "по контракту значение hashCode не может изменяться за время жизни объекта" обеспечено.

В данном случае, Вы пытаетесь скрестить ежа (контракты Java рассчитанные на работу с объектами в памяти) с удавом (базой данных, пусть реалиционную, да еще и с поддержкой транзакций). Получаете сто метров колючей проволоки.

IMHO & AFAIK
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803886
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsevjunixar...
пропущено...

Это из разряда - "..., но осуждаю"?

Не имеет значения какой стэк в моём случае используется. Будь то голый JDBC или одна из ряда ORM. К вопросу это не имеет отношения.
Мне кажется тут mayton прав

У Вас получается все скомкано в одну кучу. И объекты, и база. Отсюда и проблемы.

Термин "время жизни объекта" он же тоже не абсолютный, а от контекста зависит. Добавили объект в БД, старый грохнули, новый создали ))) Вот Вам и "по контракту значение hashCode не может изменяться за время жизни объекта" обеспечено.

В данном случае, Вы пытаетесь скрестить ежа (контракты Java рассчитанные на работу с объектами в памяти) с удавом (базой данных, пусть реалиционную, да еще и с поддержкой транзакций). Получаете сто метров колючей проволоки.

IMHO & AFAIK
+1
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803903
junixar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Petro123Leonid Kudryavtsevпропущено...

Мне кажется тут mayton прав

У Вас получается все скомкано в одну кучу. И объекты, и база. Отсюда и проблемы.

Термин "время жизни объекта" он же тоже не абсолютный, а от контекста зависит. Добавили объект в БД, старый грохнули, новый создали ))) Вот Вам и "по контракту значение hashCode не может изменяться за время жизни объекта" обеспечено.

В данном случае, Вы пытаетесь скрестить ежа (контракты Java рассчитанные на работу с объектами в памяти) с удавом (базой данных, пусть реалиционную, да еще и с поддержкой транзакций). Получаете сто метров колючей проволоки.

IMHO & AFAIK
+1
Объясняю: в вопросе были указаны условия, в которых собственно сам вопрос ставится. Я не просил обсуждать эти условия, стэк технологий или мой опыт.

Теперь повторюсь: сущности не имеют явного уникального неизменяемого поля. Ид (первичный ключ) генерируется в момент вставки записи в БД. И это здесь не обсуждается. Это исходные условия.

Вопрос - как лучше реализовать пару equals/hashCode ? Пока из всего обсуждения я вижу только одно решение - ввести суррогатное уникальное поле в сущность и заполнять значение поля в момент создания нового объекта. Данное поле соответственно сохранять в БД и там навесить условие уникальности на него. В общем-то понятно и логично - на мой взгляд. Других вариантов не вижу.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803908
no56892
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junixar,

16834799
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803912
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ты начал с этого
junixarКаждый раз натыкаюсь на этот вопрос и до сих пор не выработал для себя правильного (идеального) подхода.
Верный подход:
- PK в табличке
- время жизни об-та равно времени сессии
- не выводить объекты из сессии хибера
- не работать руками с ID объекта.
Теперь давай код, если что не выходит по этим п.п.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38803934
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
я бы представил такую аналогию:

junixarЕсли вы поместите физ.лицо в Map, а затем у физ. лица изменится хотя бы один атрибут, входящий в equals, то вы его потом просто не найдёте. Уникальных несуррогатных атрибутов у физ. лица нет. Хотя бы потому, что любой атрибут мог быть вбит оператором неправильно и потребует корректировки оператором.

1. Есть бизнес объект реального мира. Марья Ивановна. Она родилась в 1951 году и умрет в 2017 ))) Это ее "время жизни"

Она живет в квартире, иногда ходит на кладбище навестить могилу своей матери. Которая когда то умерла. Но жить на кладбище она категорически отказывается )))

2. Есть электронное представление этого объекта реального мира в виде экземпляра объекта в памяти Java Machine.

3. Есть представление этого же объекта в СУБД с поддержкой транзакций

Если мы говорим о СУБД с поддержкой транзакций, то как минимум, у нас будет 3-и больших "периода времени жизни". У объектов hibernate все по другому, я говорю с точки зрения СУБД

3.1. Данные введены но не переданы в СУБД
3.2. Данные переданы в СУБД но commit не выполнен (команда post)
3.3. Commit выполнен

СУБД, как Вы понимаете, на время жизни экземпляра объекта в памяти JVM и "контракты" глубоко наплевать.

Но и объекты, с точки зрения прикладной системы и бизнес логики, при этих трех состояниях совершенно разные. Как живая Марья Ивановна и ее уже покойная мама. И заставлять жить разные экземпляры Java отображающим объекты СУБД в этих разных состояниях в одном HashMap'е - как заставлять реальную Марью Ивановну жить на кладбище с ее бабушкой.

Иногда (например в интерфейс при вводе новых данных) - приходится. Отображаем и реальную информацию из БД и новую, фейковую, которую оператор только еще вводит с клавиатуры. Но тогда, некий фейковый ключ (в FoxPro -1,-2,-3 etc) вполне может спасти. Ввод закончился. Фейковый объект попал в БД, стал реальным. ВСЕ. Это уже другой объект. Марья Ивановна тоже когда-то 9 месяцев в животе своей матери жила, но к ее паспортным данным сейчас это не имеет никакого значения и никого не интересует.

Лирическое отступление по поводу относительности "времени жизни" и соответственно незыблемости "контрактов на время жизни объекта"

junixarТеперь повторюсь: сущности не имеют явного уникального неизменяемого поля. Ид (первичный ключ) генерируется в момент вставки записи в БД. И это здесь не обсуждается. Это исходные условия.

Вы ошибаетесь!

Сущность Марья Ивановна неизменяемый пол имеет. Нет... конечно... кто сейчас Евровидение выигрывает всем известно... но Марья Ивановна не такая!

У нее сиски 4-ого размера, отпечатки пальцев и много других уникальных характеристик.

Только... подозреваю... Вы не об этом )))


Вот. Как-то так. Отделяя вечное - СИСЬКИ. От переходящего - хибернайт и база данных )))
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38804335
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonТомин выступил несколько утрированно но в целом верно.

Какой утрировано. Это цитаты практически. Включая уровень аргументов и стиль общения :(

Leonid KudryavtsevЕсли нет PK, не понятно, как запись идентифицировать. При delete например
...
Я в целом, если без ПК живете хорошо - ну живите, мешать не буду. Но для меня таблица без ПК как-то нонсенс )))

Надо различать PK с точки зрения БД и реальный PK, который может быть.
Например в той таблице - там есть три поля, которые дают уникальность. Что позволяет и удалять записи, и написать equals/hash. Просто в БД нельзя создавать ни уникальный индекс (хотя это скорее тараканы админов), ни PK.

А использовать timestamp в качестве PK нельзя. Никак. Мало ли что. Есть UUID и этого достаточно.

Либо sequence какой-нибудь, главное сначала брать его из БД, присваивать его новому объекту и жить с ним. Генерировать ID при записи- это не очевидный, но гарантированный, путь к проблемам потом, когда менять что-то будет уже лень.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38804342
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junixarТеперь повторюсь: сущности не имеют явного уникального неизменяемого поля. Ид (первичный ключ) генерируется в момент вставки записи в БД. И это здесь не обсуждается. Это исходные условия.

У твоей машины нет одного колеса. Это не обсуждается, это исходные условия, чинить не будем. Но ехать до Казани надо. Подскажи, что делать?
Генерация ID в момент вставки- это архитектурная ошибка. Она НЕ ИСПРАВЛЯЕТСЯ нормально НИКАКИМИ средствами.


junixarВопрос - как лучше реализовать пару equals/hashCode ? Пока из всего обсуждения я вижу только одно решение - ввести суррогатное уникальное поле в сущность и заполнять значение поля в момент создания нового объекта. Данное поле соответственно сохранять в БД и там навесить условие уникальности на него. В общем-то понятно и логично - на мой взгляд. Других вариантов не вижу.

Зря.
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38804360
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey TominНу если админы смотрят на тебя сурово и говорят
Был такой анекдот в СССР про то, почему на Красной площади сексом не занимаются...
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38804375
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Арсеньев,

А да забыл on-topic

Про equals - хорошо написал mayton в первом же коменте.
hashCode должен соответствовать двум требованиям

1. Если два экземпляра класса equals, то и hashCode equals.
2. Вычисление hashCode не должно быть медленнее equals (в идеале гораздо быстрее).

Совсем идеальный hashCode обеспечивает равномерное распределение количества объектов по своим значениям. :)
...
Рейтинг: 0 / 0
Правильный подход с реализацией equals/hashCode ?
    #38804385
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
junixarЕсли вы поместите физ.лицо в Map, а затем у физ. лица изменится хотя бы один атрибут, входящий в equals, то
это другое Физ лицо. :)
Вы случайно не путаете с вопросом про текучесть HashMap при изменяющемся экземпляре ключа?
...
Рейтинг: 0 / 0
18 сообщений из 43, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / Правильный подход с реализацией equals/hashCode ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]