Меняешь значение в базе

у меня отображение таблицы на объект, объект привязан к контексту

ауууу, фп боги, вы где

я вообще из базы только читаю и трансфомирую. cqrs все дела

намного же проще, поднять объект из бд, который привязан к контексту, сеттером поменять филд и при выходе из метода транзакция закоммитит изменения

я вообще из базы только читаю и трансфомирую. cqrs все дела

А как в базу попадают данные, которые ты читаешь?

нахера тут иммутабельность?

намного же проще, поднять объект из бд, который привязан к контексту, сеттером поменять филд и при выходе из метода транзакция закоммитит изменения

при подходе который продвигает hibernate - да

но это не единственный подход

при подходе который продвигает hibernate - да

я бы сказал такой подход продвигает JPA

да

и вообще любая ORM

но я боюсь что hibernate и JPA попадает в категорию паттернов "не очень"

тут же @dmsol сказал, что логика в них это боль, то есть логики там не должно быть. выходит, что они должны просто сеттить/возвращать значение, тогда о каком контроле идет речь? ты через геттер вернешь все то же самое значение поля, только кода будет намного больше

это дань традиции, когда процедурщики начали массово мигрировать в Java сложился такой подход, сейчас есть тенденция уходить от этого и как минимум оставлять только геттеры(ну по крайней мере у меня)

т.е. делать объекты иммутабельными

но я боюсь что hibernate и JPA попадает в категорию паттернов "не очень"

давай кейс с иммутабельным объектом и крудом в базе

это дань традиции, когда процедурщики начали массово мигрировать в Java сложился такой подход, сейчас есть тенденция уходить от этого и как минимум оставлять только геттеры(ну по крайней мере у меня)

Снова вопрос - зачем, если логики там не должно быть, а поле ты все равно и так возвращаешь?Если ты не хочешь вообще его никак наружу выставлять - делаешь приватным и всё. Зачем лишний геттер?

Логировать использование

Снова вопрос - зачем, если логики там не должно быть, а поле ты все равно и так возвращаешь?Если ты не хочешь вообще его никак наружу выставлять - делаешь приватным и всё. Зачем лишний геттер?

дело в том, что так просто не избавиться от наследия, многие фреймворки на них опираются.

Поставить бряк в дебаге

видеть интерфейс объекта

давай кейс с иммутабельным объектом и крудом в базе

update отдельного поля, когда ты имеешь маппинг из объектов в бд - как делается в jdbc обертках на scala

Снова вопрос - зачем, если логики там не должно быть, а поле ты все равно и так возвращаешь?Если ты не хочешь вообще его никак наружу выставлять - делаешь приватным и всё. Зачем лишний геттер?

еще раз, во первых дань традиции, а во вторых хоть какой то контроль над пропертей в будущем если захочу добавить логику в геттер независимо от того хочу я делать это сейчас или нет, к тому же JSON либы всякие лучше понимают на уровне геттеров и сеттеров обычно, опять же разные аннотации по разному могут вешаться

Поставить бряк в дебаге

тут противоречие, если отталкиваться, что сеттеры чистые

без мутабельности

Поставить бряк в дебаге

По-сути ради этого можно юзать геттеры

Снова вопрос - зачем, если логики там не должно быть, а поле ты все равно и так возвращаешь?Если ты не хочешь вообще его никак наружу выставлять - делаешь приватным и всё. Зачем лишний геттер?

Потому что ты хранишь себе список, а потом бац, и понимаешь, что в памяти он не помещается. Вместо списка теперь хранишь штуку, которая батчом вытаскивает данные из оффхип кэша

еще раз, во первых дань традиции, а во вторых хоть какой то контроль над пропертей в будущем если захочу добавить логику в геттер независимо от того хочу я делать это сейчас или нет, к тому же JSON либы всякие лучше понимают на уровне геттеров и сеттеров обычно, опять же разные аннотации по разному могут вешаться

а ещё, очень сложно найти людей, которые понимают почему иногда сеттеры не нужны и как писать иначе

Хотя сам не люблю геттеры/сеттеры

update отдельного поля, когда ты имеешь маппинг из объектов в бд - как делается в jdbc обертках на scala

т.е. я апдейчу поле, получаю новый объект, а потом делаю персист?

только по скольку это голый ждбц привязку к контексту я не имею

у тебя уже есть объект)

просто голый джава объект?

просто голый джава объект?

Что значит контекст

Дима

ну, ты его как получил?

Потому что ты хранишь себе список, а потом бац, и понимаешь, что в памяти он не помещается. Вместо списка теперь хранишь штуку, которая батчом вытаскивает данные из оффхип кэша

то есть уже логика в геттере?

Что значит контекст

то, что связывает твой объект с базой

запросом из базы достал?

запросом из базы достал?

ага

ну вот. он у тебя есть

так

чего уж греха таить, в джаве народ намного более приземлённый.

А зачем тебе связывать его с базой

JPA же

персистентность

А зачем тебе связывать его с базой

допустим я использую ORM like JPA

то есть уже логика в геттере?

Естественно. Более того, внутренний стэйт поменялся, но всем на это срать.

там все объекты живут в контексте

А если не используешь

тогда не надо

и Николай мне сейчас рассказывает как будет в скале

Естественно. Более того, внутренний стэйт поменялся, но всем на это срать.

после такого уходят на скалу в мир иммутабельности

Естественно. Более того, внутренний стэйт поменялся, но всем на это срать.

Так все же говорят тут, что логика в геттере - это зло? Так правда-то где?

Так все же говорят тут, что логика в геттере - это зло? Так правда-то где?

мне норм

после такого уходят на скалу в мир иммутабельности

некоторые еще бухать начинают и в жопу долбиться

Так все же говорят тут, что логика в геттере - это зло? Так правда-то где?

я лишь добавлю, серьёзная бизнес-логика

например если вы свертку сделали внутри геттера

ок

Зло наверно в сеттерах логику имееть

но если вы начинает хуйню творить

значит ты стопудово сможешь сделать копию объекта с измененным полем, и потом записать это дело в базу. копия у тебя уже есть

Когда добавил одно, а в стейт попало другое

значит ты стопудово сможешь сделать копию объекта с измененным полем, и потом записать это дело в базу. копия у тебя уже есть

объект обычный, джавовый? речь про ждбц?

тогда зачем ты у меня что-то спрашиваешь, если ты пишешь как ты хочешь, тебе норм?)) по такому подходу можно сказать, что любой самый уродливый паттерн ОК, раз я на нем пишу и мне норм)

тогда зачем ты у меня что-то спрашиваешь, если ты пишешь как ты хочешь, тебе норм?)) по такому подходу можно сказать, что любой самый уродливый паттерн ОК, раз я на нем пишу и мне норм)

ты по такому подходу постами выше на джаву пописал, но ничего

значит ты стопудово сможешь сделать копию объекта с измененным полем, и потом записать это дело в базу. копия у тебя уже есть

если вы о JPA и в частности Hibernate то не все так просто

даже копию объекта там сделать проблематично

если вы о JPA и в частности Hibernate то не все так просто

да, потому что можно вызвать переполнения кэша и локальный пзцд

ERROR: S client not available

ты по такому подходу постами выше на джаву пописал, но ничего

я не понял смысла того, что ты сказал, поясни?

тогда зачем ты у меня что-то спрашиваешь, если ты пишешь как ты хочешь, тебе норм?)) по такому подходу можно сказать, что любой самый уродливый паттерн ОК, раз я на нем пишу и мне норм)

я ничего не спрашиваю. Я говорю про реальные кейсы, а не абстрактные холивары

я не понял смысла того, что ты сказал, поясни?

Саша выше сказал

когда тебе делать надо, а не мешки ворочить

объект обычный, джавовый? речь про ждбц?

у тебя есть маппинг объект <-> база. описанный в каком-то виде. объект тут может быть кейс классом, просто классом, даже мапой думаю тоже может быть. не чистый jdbc, обертки над ним, и либы типа slick

Ну, тогда ладно, с таким подходом спорить нет смысла, норм так норм)

у тебя есть маппинг объект <-> база. описанный в каком-то виде. объект тут может быть кейс классом, просто классом, даже мапой думаю тоже может быть. не чистый jdbc, обертки над ним, и либы типа slick

но любые изменения попадают в базу только после коммита, так?

просто мы тогда не получаем накладных расходов

и твой подход можно использовать

но любые изменения попадают в базу только после коммита, так?

да

я тебя понял

чаще всего используют кейс классы скаловские, потому что по ним можно автоматически сгенерировать маппинги туда-обратно с помощью макросов/shapeless

а вот еще такой, я когда поменял объект, скаловский маппер автоматом мне апдейт запрос сконструирует?

как под капотом это все работает?

ты имеешь в виду - diff полей построить и по нему апдейт сформировать?

ага

эта прям сама либа умеет такое анализировать? или самому мапперы писать?

вот есть у нас spring jdbc template, там мапперы сами пишем

там, вроде, был хитрый маппер, который по рефлексии маппит бин на поля запроса

ни шутя

но он не такой быстрый, как хотелось бы

http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/BeanPropertyRowMapper.html

такого в готовом виде чтобы предоставляла какая-то из либ - не видел. может быть кто-то другой встречал. тут скорее всего будет сводится к тому что ты 1) перезапишешь весь объект если не хочешь заморачиваться 2) напишешь запрос на апдейт определенных полей сам 3) заморочишься с диффом и сделаешь что-то свое. весьма возможно что 3 уже кто-то сделал

надо бы поискать

Так я не понял, что в итоге с getter/setter?

генерируй идеей и не трогай больше)

Так я не понял, что в итоге с getter/setter?

используй лобок

*ломбок

*ломбок

сам то используешь?)

да

уже полгода наверно

только 1 косяк обнаружил для себя, а так годная либа