Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: скала слик  [new]
Пылинка
Member

Откуда: СПб
Сообщений: 365
mayton
andreykaT
проблема нативскуэля в том что если у тебя доменная модель поменяется допустим, ты банально увидишь что у тебя что то сломалось только когда тестами гонять будешь. если они вообще у тебя будут и будут покрывать этот кейс. поэтому хотелось бы оставить дсл.

Выкрутился

Я вообще в ужасе - как же живут чисто sql-программисты, типа на PL/SQL, и не тужат.
18 мар 19, 22:04    [21836631]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
забыл ник
Member

Откуда:
Сообщений: 3052
mayton
Не знаю что это. Но этот код ужасен.


Вопрос привычки. 12 строк кода на 6 джойнов, по-моему очень даже неплохо.

Вот пример джойна на хаскел

select $
from $ \(b, p) -> do
where_ (b ^. BlogPostAuthorId ==. p ^. PersonId)
orderBy [asc (b ^. BlogPostTitle)]
return (b, p)


После 15 лет на джаве может показаться мозголомным, кому-то элегантным
18 мар 19, 23:41    [21836671]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов
andreykaT
юзай проекции. они тебя спасут. если тебе не нравится что хибер что-то лишнее на твой взгляд вытягивает.


Ничем оно не поможет. Вот сущность:

public class Entity {

	@Id
	@Column("SURROGATE_KEY")
	protected Long id;

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "NATURAL_KEY_REF", referencedColumnName = "NATURAL_KEY")
	private Other other;

}


а почему тут работать не будет? Я думал проблемы с onetoone ?
там FetchType.LAZY работать никогда не будет, потому что так устроен хибернейт. Предлагаю дальше тему не развивать, поскольку примеров масса и хибернейт - это УГ, факт.
19 мар 19, 08:43    [21836816]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
а почему тут работать не будет? Я думал проблемы с onetoone ?
19 мар 19, 09:35    [21836867]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
mayton
Member

Откуда: loopback
Сообщений: 42985
Пылинка
mayton
пропущено...

Выкрутился

Я вообще в ужасе - как же живут чисто sql-программисты, типа на PL/SQL, и не тужат.

Если меняется доменная модель то процедуры, вьюшки и прочие объекты домена БД переходят в invalid state.
Далее - задача PLSQL разработчика - просто просмотреть список объектов и по каждому принять решение.

Но поскольку Java ORM создавались в отрыве от конкретной БД то такой функционал им недоступен.
19 мар 19, 10:40    [21836961]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
mayton,
Это в оракле.
В остальных вроде этого нет.
19 мар 19, 10:46    [21836970]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3355
Озверин
а почему тут работать не будет? Я думал проблемы с onetoone ?
ну OneToOne - известная грабля, решается обещанием что запись есть при помощи optional=false, однако, lazy в ManyToOne/OneToOne с натуральным ключем при наличии суррогатного не умеет, ну просто потому что в сессии сущности только по одному ключу доступны: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/EntityType.java#L461
19 мар 19, 11:26    [21837035]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
Андрей Панфилов
OneToOne
такое отношение и бд разрабы не любят.
Неудивительно что грабли.
19 мар 19, 11:28    [21837041]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Пылинка
Member

Откуда: СПб
Сообщений: 365
mayton
Пылинка
пропущено...

Я вообще в ужасе - как же живут чисто sql-программисты, типа на PL/SQL, и не тужат.

Если меняется доменная модель то процедуры, вьюшки и прочие объекты домена БД переходят в invalid state.
Далее - задача PLSQL разработчика - просто просмотреть список объектов и по каждому принять решение.

Но поскольку Java ORM создавались в отрыве от конкретной БД то такой функционал им недоступен.

это что такое - в отрыве от конкретной БД? Ничего не понял.
1) объекты БД точно так же перейдут (или не перейдут) в это состояние.
2) если вам нужны сущности ORM - то у вас что, не работает поиск объявления и использования классов JAVA? Точно так же получите весь список.
19 мар 19, 12:05    [21837125]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Озверин
Member

Откуда: Ростов-на-Дону
Сообщений: 5183
Андрей Панфилов
Озверин
а почему тут работать не будет? Я думал проблемы с onetoone ?
ну OneToOne - известная грабля, решается обещанием что запись есть при помощи optional=false, однако, lazy в ManyToOne/OneToOne с натуральным ключем при наличии суррогатного не умеет, ну просто потому что в сессии сущности только по одному ключу доступны: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/EntityType.java#L461


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

https://stackoverflow.com/questions/30082281/manytoonefetch-fetchtype-lazy-doesnt-work-on-non-primary-key-referenced-co
https://hibernate.atlassian.net/browse/HHH-12053
19 мар 19, 12:27    [21837162]     Ответить | Цитировать Сообщить модератору
 Re: скала слик  [new]
Андрей Панфилов
Member

Откуда: Москва > Melbourne
Сообщений: 3355
Озверин
а потом меня спрашивают, почему я могу предпочесть запросы сущностям со связями.
Ну это только одна из проблем, а там их горы, вот примеры:

  • захотел в старом хибере чтобы он мне Stream возвращал вместо списка, начал смотреть как реализовали в новом: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/internal/ScrollableResultsIterator.java - збс, в итераторе вызов hasNext() курсор двигает сколько угодно раз
  • захотели блокировки в нужных местах делать, вроде паттерн стандартный: блокируем запись по id, потом обновляем сущность из БД, а вот нельзя так если в сущности есть @Version-поле - это поделие зачем-то в запрос условие на штамп версии вставляет: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/lock/PessimisticWriteSelectLockingStrategy.java#L111

    ну и в общем так постоянно: чуть в сторону от элементарных вещей и сразу грабли на ровном месте.
  • 19 мар 19, 12:42    [21837183]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 42985
    Пылинка
    mayton
    пропущено...

    Если меняется доменная модель то процедуры, вьюшки и прочие объекты домена БД переходят в invalid state.
    Далее - задача PLSQL разработчика - просто просмотреть список объектов и по каждому принять решение.

    Но поскольку Java ORM создавались в отрыве от конкретной БД то такой функционал им недоступен.

    это что такое - в отрыве от конкретной БД? Ничего не понял.
    1) объекты БД точно так же перейдут (или не перейдут) в это состояние.
    2) если вам нужны сущности ORM - то у вас что, не работает поиск объявления и использования классов JAVA? Точно так же получите весь список.

    1) Я не буду писать много букв. Много лет назад были выпущены статьи на тему недостатков ORM.
    Вкратце оно называется object relational impedance mismatch. Поищите.

    2) Мой комментарий касался отзывчивости среды разработки БД к изменениям (например удалена колонка из таблицы).
    И неотзывчивости ORM-средств которые детектируют это изменние только в фазе непосредственного выполнения.
    Даже не в компилляции. Тоже самое кажется спрашивал и мой собеседник. Его беспокоила скорость реакции
    системы на изменения. Ну ... я так это понял.
    19 мар 19, 13:56    [21837320]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Пылинка
    Member

    Откуда: СПб
    Сообщений: 365
    Андрей Панфилов
  • захотели блокировки в нужных местах делать, вроде паттерн стандартный: блокируем запись по id, потом обновляем сущность из БД, а вот нельзя так если в сущности есть @Version-поле - это поделие зачем-то в запрос условие на штамп версии вставляет:

  • Зачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?
    19 мар 19, 18:56    [21837683]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 42985
    Пылинка
    Андрей Панфилов
  • захотели блокировки в нужных местах делать, вроде паттерн стандартный: блокируем запись по id, потом обновляем сущность из БД, а вот нельзя так если в сущности есть @Version-поле - это поделие зачем-то в запрос условие на штамп версии вставляет:

  • Зачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?

    А с каких пор оптимистическая стала рекомендованным шаблоном?
    19 мар 19, 19:04    [21837695]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Пылинка
    Member

    Откуда: СПб
    Сообщений: 365
    Озверин
    а потом меня спрашивают, почему я могу предпочесть запросы сущностям со связями.
    Я так понимаю, был какой-то выход, но даже этот выход хибернейтовсцы умудрились сломать:

    "Мы" уже давно пришли к выводу что такие связи в ORM - зло. Аналог их встроен в ADF, у нас был "корпоротивный стандарт" (длительный опыт) - никак связи не использовать.
    19 мар 19, 19:05    [21837697]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Пылинка
    Member

    Откуда: СПб
    Сообщений: 365
    mayton
    А с каких пор оптимистическая стала рекомендованным шаблоном?

    А с какого там тогда Version поле?
    19 мар 19, 19:06    [21837699]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    mayton
    Member

    Откуда: loopback
    Сообщений: 42985
    Пылинка
    mayton
    А с каких пор оптимистическая стала рекомендованным шаблоном?

    А с какого там тогда Version поле?

    А я ничего вообще не говорил про Version. Интересный у нас разговор получается. Может нам стоит вернуться в начало?
    19 мар 19, 19:11    [21837706]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    забыл ник
    Member

    Откуда:
    Сообщений: 3052
    mayton,

    Пылинка имеет ввиду, что использовать одновременно и поле Version и пессимистичную блокировку немного бессмысленно. Тут или трусы или крестик
    19 мар 19, 20:20    [21837754]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3355
    Пылинка
    Зачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?
    не автоматом, а костылем. Оптимистичная блокировка полезна в довольно ограниченных случаях, а именно когда пользователь пытается сохранить строку, а мы его отшиваем и говорим: тут пока ты думал что-то поменялось, иди и разбирайся сам что произошло, в остальных случаях пользы от нее никакой: ну на кой черт нам что-то обрабатывать, а потом в коммите словить ошибку, что не получилось? мы же наверняка знаем что будем менять, поэтому на порядок проще заблокировать то что нужно, а потом уже обновлять. С хиберовским же подходом, получается так, что он пуляет кривой select for update в базу, не получает результата и кидает StaleObjectStateException, от которого толку вообще никакого нет, вот что с ним делать? Ловить в цикле пока не пропадет? а как понять что вообще случилось? Ситуация что строчки в базе нет может быть вызвана по крайней мере тремя причинами, нам еще каждую гипотезу проверять и тоже перехватывать исключения? Вот на ровном месте получается куча стремного кода.
    19 мар 19, 20:23    [21837755]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    забыл ник
    Member

    Откуда:
    Сообщений: 3052
    Андрей Панфилов
    Пылинка
    Зачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?
    не автоматом, а костылем. Оптимистичная блокировка полезна в довольно ограниченных случаях, а именно когда пользователь пытается сохранить строку, а мы его отшиваем и говорим: тут пока ты думал что-то поменялось, иди и разбирайся сам что произошло, в остальных случаях пользы от нее никакой: ну на кой черт нам что-то обрабатывать, а потом в коммите словить ошибку, что не получилось? мы же наверняка знаем что будем менять, поэтому на порядок проще заблокировать то что нужно, а потом уже обновлять. С хиберовским же подходом, получается так, что он пуляет кривой select for update в базу, не получает результата и кидает StaleObjectStateException, от которого толку вообще никакого нет, вот что с ним делать? Ловить в цикле пока не пропадет? а как понять что вообще случилось? Ситуация что строчки в базе нет может быть вызвана по крайней мере тремя причинами, нам еще каждую гипотезу проверять и тоже перехватывать исключения? Вот на ровном месте получается куча стремного кода.


    Зачем тогда вообще использовать Version?
    19 мар 19, 20:33    [21837759]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3355
    забыл ник
    Зачем тогда вообще использовать Version?
    Без @Version пользаки будут данные друг друга тихо перетирать, если вы предлагаете вместо @Version пилить что-то свое, то это опять же будет камень в сторону хибера.
    19 мар 19, 20:43    [21837764]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    забыл ник
    Member

    Откуда:
    Сообщений: 3052
    Андрей Панфилов
    забыл ник
    Зачем тогда вообще использовать Version?
    Без @Version пользаки будут данные друг друга тихо перетирать, если вы предлагаете вместо @Version пилить что-то свое, то это опять же будет камень в сторону хибера.


    То что хибер говно, я не спорю от слова совсем. Но ваш юзкейс все равно непонятен. Получается что у вас есть как минимум два места изменения одной сущности с существенно различающимся паттерном, в одном случае пессимистичная блокировка, в другом оптимистичная. Но пессимистичная используется когда высокий шанс коллизии, а если такой шанс есть, то имеет смысл использовать пессимистик-лок ВСЕГДА, как-то у меня картина не сходится. Это не в укор, хоть я и повидал много бизнес-доменов, но такое вижу впервые, поэтому и интересно узнать в каких случаях такое бывает.

    Обычно есть какие-то пользовательские операции и батч процесс над одними и теми же данными, но обычно они моделируются разными средствами, и писать батчинг на хибернейт как-то совсем не айс. У меня это вообще обычно отдельным модулем, в нативном sql-запросе, с отклбченным автокомитом, блокировкой всей таблицы на это время, а еще лучше просто использовать другую таблицу да и все. Стараюсь придерживаться правила - каждая сущность может быть изменена ровно одним способом, поэтому и таких проблем не встречал.
    Было бы интересно послушать обоснование вашего выбора.
    19 мар 19, 21:22    [21837787]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Андрей Панфилов
    Member

    Откуда: Москва > Melbourne
    Сообщений: 3355
    забыл ник
    Но пессимистичная используется когда высокий шанс коллизии, а если такой шанс есть, то имеет смысл использовать пессимистик-лок ВСЕГДА, как-то у меня картина не сходится. Это не в укор, хоть я и повидал много бизнес-доменов, но такое вижу впервые, поэтому и интересно узнать в каких случаях такое бывает.
    Ну сначала вы придумали уловное разделение на пессимистичные/оптимистичные и всегда/невсегда, а теперь пытаетесь заставить меня обосновать такое разделение, ну давайте попробуем.

    разделение на всегда/невсегда неверное, просто потому что при записи (обновлении) в базу блокировка возникает всегда и длится от момента когда мы захватили строку до коммита/отката транзакции, правильно здесь делить на явные/неявные. Поэтому если мы на 100% уверены, что вот в этом определенном месте мы будем писать в базу (к примеру от пользователя пришел запрос на обновление), какого-либо смысла не ставить блокировку нет - она так или иначе возникнет, вопрос здесь только в том когда она возникнет, и вот здесь уже начинаются нюансы, а именно:
    - база позволяет "подсмотреть" заблокирована строка, которую мы собираемся обновлять или нет, соответственно если мы пытаемся поставить блокировку сразу, то у нас есть возможность указать сколько времени вообще ждать, чтобы не обламывать нашего любимого пользователя, а "сразу" сказать что ждать тут нечего
    - если мы явные блокировки там где нужно не ставим, то начинаем ловить лулзы уже из-за неявных (там всякие автофлаши и пр.) - и здесь уже никаких таймаутов нет, и соломку не подложить

    разделение на пессимистичные/оптимистичные вообще какое-то кривое, потому что из названия суть непонятна - просто так повелось, основная задача в "оптимистичных" - это производить обновления данных в базе актуальным вектором изменений, мы просто маркируем изменения штампом версии и перед тем как обновить сравниваем что там в базе, а блокировки здесь вообще никакой нет, более того, что мешает после подобной оптимистичной проверки заблокировать строку, чтобы больше никто не влез? ничего не мешает и противоречия/конфликта/пр здесь никакого я не вижу, более того, сам подход следовало бы назвать не "оптимистичным", а "наивным", ну вот что толку от того, что из 10 записей мы обновили 9, а на десятой обломались, потому что кто-то другой влез? мы во-первых, свою задачу не выполнили, во-вторых еще кого-то заблокировали.
    19 мар 19, 22:47    [21837864]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    Petro123
    Member

    Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
    Сообщений: 38643
    забыл ник
    mayton,

    Пылинка имеет ввиду, что использовать одновременно и поле Version и пессимистичную блокировку немного бессмысленно. Тут или трусы или крестик

    +1
    19 мар 19, 22:58    [21837873]     Ответить | Цитировать Сообщить модератору
     Re: скала слик  [new]
    andreykaT
    Member

    Откуда:
    Сообщений: 2433
    Странный спор. Это как спорить что лучше - КамАЗ или Матиз )). Ну смотря что тебе надо.

    А насчёт того что хибер гапно .. чтобы понять что хибер не гапно можно просто поюзать Слик.

    Кстати, я так понимаю по первому сообщению в этом топике там улучшать особо нечего и некуда?
    19 мар 19, 23:43    [21837893]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Java Ответить