Comments 5
Честно говоря сложно понять, в чем проблема, когда нет результатов вывода набора println.
Использовать data class для JPA сущности ... избыточно ... так как придётся переопределять методы equals и hashcode.
Не совсем верно. В котлине дата классы придумали для создания неизменяемых классов (что видно в приведенном Вами декомпилированном коде - финальное поле и отсутствие сеттера).
В первом случае (генерации id на стороне приложения) - поля экземпляра инициализируются в момент создания класса и больше не изменяются. Во втором случае - поле id заполняется в только в момент сохранения в БД, и это уже другой экземпляр, у него даже ссылка будет другая.
Таким образом основная проблема в Вашем случае - не необходимость переопределять equals и hashCode, а наличие неконтролируемого числа экземпляров дата класса, что может привести к утечкам памяти.
>>Честно говоря сложно понять, в чем проблема, когда нет результатов вывода набора println.
Семен Семенович. Пока я воевал с форматированием кода комментарии похерились. Спасибо за указание.
>>Не совсем верно. В котлине дата классы придумали для создания неизменяемых классов (что видно в приведенном Вами декомпилированном коде - финальное поле и отсутствие сеттера).
В декомпилированном коде отсуствует setter так поле отмечено как val. Если изименить на var появится public final setter.
>Таким образом основная проблема в Вашем случае - не необходимость переопределять equals и hashCode, а наличие неконтролируемого числа экземпляров дата класса, что может привести к утечкам памяти.
Это уже про сериализацию, я обозначил в статье как "side эффект". Дело в том, что переопределив equals и hashcode я могу сделать так, чтобы объект до сохранения и после были равны, например исключив id из equals и взяв другой ключ для сравнения (например isbn, инн, др идентификатор). Но зачем указывать data и потом переопределять методы, которые data под капотом автоматически переопределяет.
Data class просто избыточен в качестве JPA entity, т.к. всё что он генерит просто не нужно и опасно - equals/hashCode/toString/copy. Для большей веселости и наглядности добавьте join-поля, и начнется веселуха.
Ну если очень сильно нужен copy (при огромном количестве полей), то может овчинка и стоит выделки (проще будет заглушить equals/hashCode/toString, чем писать copy вручную).
Разверните мысль насчет join-ов пожалуйста. В чем веселье и при каких условиях будет весело?
Термин "join-поля" я выбрал неудачно (т.к join появятся только при соответствующей настройке аннотаций), правильно было сказать "завимости" (one-to-many, many-to-one, и тд)
Веселье будет во всех этих методах (если вы их не переопределите), поскольку они вызовут подгрузку dependencies (и если они также "прекрасно" написаны, то всё дерево зависимостей загрузится на вызов непереопределенного equals/hashCode, и всё ваше lazy сразу идет под хвост)
Подходит ли data class для JPA entity?