ReSQL.ru
     
powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Новые веяния
25 сообщений из 79, страница 2 из 4
  2  все
Новые веяния
    #39980781
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
chpasha
andreykaT
Имхо критериа апи гораздо сложнее и к чтению и к пониманию нежели хкл или жпкл. Те хоть на скуль издали одним глазом похожи.

имхо тоже, особенно когда начинаются join-ы и подзапросы. так это я еще пол истории рассказал, на самом деле это даже не Criteria-API, а нечто критериа-подобное, т.е. велосипед по сути, в котором до 5 хибера даже left-join не работали. паноптикум короче


чет вы страсти какие-то рассказываете... у Criteria-API есть compile-time валидация (это конечно если вы не профукали включить хиберовский annotation processor), одного только этого достаточно для обязательного применения Criteria-API и нивелирует все остальные недостатки, которых нет, потому что сложнее/легче - это никакой не критерий, а если же говорить про выразительность, то я знаю только один проблемный случай: сущности типа (child_id, parent_id) и нужно с двух сторон доставать - но это вообще косяк JPQL, потому что про UNION в нем забыли
...
Рейтинг: 0 / 0
17.07.2020, 09:56
| Ответить | Цитировать | Написать  
Новые веяния
    #39980791
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
Пардон за офтоп
ребята есть ли кто живой из ЦРПТ по табачному направлению, жутко нужна консультация
зы Топик популярный
...
Рейтинг: 0 / 0
17.07.2020, 10:13
| Ответить | Цитировать | Написать  
Новые веяния
    #39980804
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Alexey Tomin
Не от языка это зависит. Да и не новое это.
Да ладно, профессиональная деформация связанная с языком и предметной областью всегда имеет место быть: у тех кто пишет бэк за годы работы уже подсознательно отложилось, что "обрабатывать данные в контроллере западло", у тех кто пишет UI тоже подсознательное "обрабатывать данные в UI-потоке западло" - отсюда и CompletableFuture на ровном месте, если смотреть в сторону криптографии, то там у чуваков вместо API вообще какие-то помои, при этом "считается" что это якобы нормально То что недавно про микросервисы было: если возникла проблема с микросервисами, то это значит что у вас слишком мало микросервисов - нужно еще больше (или: обрабатывать данные у себя западло, пусто кто-то другой делает ).
...
Рейтинг: 0 / 0
17.07.2020, 10:21
| Ответить | Цитировать | Написать  
Новые веяния
    #39980845
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Андрей Панфилов
чет вы страсти какие-то рассказываете

чет у тебя Андрей с глазами проблемы, но ты, как всегда поспешаешь всех *уями обложить

цитирую еще раз

на самом деле это даже не Criteria-API, а нечто критериа-подобное, т.е. велосипед по сути

Андрей Панфилов
потому что сложнее/легче - это никакой не критерий

согласно кивает. сразу ведь понятно, что тут происходит, выразительно и лаконично
Код: java
1.
2.
3.
4.
5.
6.
7.
CriteriaQuery<Employee> query = criteriaBuilder.createQuery(Employee.class);
   Root<Employee> employee = query.from(Employee.class);
   ListJoin<Employee, Task> tasks = employee.join(Employee_.tasks);
   query.select(employee)
        .where(criteriaBuilder.equal(tasks.get(Task_.supervisor), employee.get(Employee_.name)));
   TypedQuery<Employee> typedQuery = entityManager.createQuery(query);
   List<Employee> employees = typedQuery.getResultList();


то ли дело
Код: java
1.
2.
3.
select  e from Employee e 
inner join fetch e.tasks 
where xxx"
...
Рейтинг: 0 / 0
17.07.2020, 11:45
| Ответить | Цитировать | Написать  
Новые веяния
    #39980860
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Андрей Панфилов
чет вы страсти какие-то рассказываете... у Criteria-API есть compile-time валидация (это конечно если вы не профукали включить хиберовский annotation processor), одного только этого достаточно для обязательного применения Criteria-API и нивелирует все остальные недостатки, которых нет, потому что сложнее/легче - это никакой не критерий, а если же говорить про выразительность, то я знаю только один проблемный случай: сущности типа (child_id, parent_id) и нужно с двух сторон доставать - но это вообще косяк JPQL, потому что про UNION в нем забыли


ИМХО Criteria API не удобная вещь.
Синтаксис сложный и запутанный. Легко написать фигню.
А потом долго отлаживать через логи, смотря какой запрос сгенерился.
По мне, удобнее использовать @Query c nativeQuery.
...
Рейтинг: 0 / 0
17.07.2020, 12:14
| Ответить | Цитировать | Написать  
Новые веяния
    #39980886
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
chpasha
Андрей Панфилов
чет вы страсти какие-то рассказываете

чет у тебя Андрей с глазами проблемы, но ты, как всегда поспешаешь всех *уями обложить

цитирую еще раз

на самом деле это даже не Criteria-API, а нечто критериа-подобное, т.е. велосипед по сути


Андрей Панфилов
потому что сложнее/легче - это никакой не критерий

согласно кивает. сразу ведь понятно, что тут происходит, выразительно и лаконично
Код: java
1.
2.
3.
4.
5.
6.
7.
CriteriaQuery<Employee> query = criteriaBuilder.createQuery(Employee.class);
   Root<Employee> employee = query.from(Employee.class);
   ListJoin<Employee, Task> tasks = employee.join(Employee_.tasks);
   query.select(employee)
        .where(criteriaBuilder.equal(tasks.get(Task_.supervisor), employee.get(Employee_.name)));
   TypedQuery<Employee> typedQuery = entityManager.createQuery(query);
   List<Employee> employees = typedQuery.getResultList();


то ли дело
Код: java
1.
2.
3.
select  e from Employee e 
inner join fetch e.tasks 
where xxx"



так...

Код: java
1.
CriteriaQuery<Employee> query = criteriaBuilder.createQuery(Employee.class);


и
Код: java
1.
2.
   TypedQuery<Employee> typedQuery = entityManager.createQuery(query);
   List<Employee> employees = typedQuery.getResultList();



никакого отношения к Criteria API не имеет - это инфраструктурный код, который никто не догадался загнать под капот. Остается только:

Код: java
1.
2.
3.
   ListJoin<Employee, Task> tasks = employee.join(Employee_.tasks);
   query.select(employee)
        .where(criteriaBuilder.equal(tasks.get(Task_.supervisor), employee.get(Employee_.name)));



код просто невероятно сложный (на самом деле он неправильный - я уже описывал почему)
...
Рейтинг: 0 / 0
17.07.2020, 12:47
| Ответить | Цитировать | Написать  
Новые веяния
    #39980901
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
chpasha,

удивительно, можно, оказывается, один код показать с инфраструктурой, а другой без, а потом заявить что оппонент в глаза долбится.
...
Рейтинг: 0 / 0
17.07.2020, 13:11
| Ответить | Цитировать | Написать  
Новые веяния
    #39980923
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Андрей Панфилов
удивительно, можно, оказывается, один код показать с инфраструктурой, а другой без, а потом заявить что оппонент в глаза долбится

ну я и where еще подсократил - лень было дописывать, мы же не кол-во строчек собрались считать. смысла сказанного это не меняет

что происходит тут нужно вкуривать, кто тут на ком стоял
Код: java
1.
2.
3.
  ListJoin<Employee, Task> tasks = employee.join(Employee_.tasks);
   query.select(employee)
        .where(criteriaBuilder.equal(tasks.get(Task_.supervisor), employee.get(Employee_.name)));


а что тут
Код: sql
1.
2.
3.
4.
5.
entityManager.createQuery("""
      select  e from Employee e 
           inner join fetch e.tasks 
      where xxx
"""


понятно сразу много кому

а вот так, к слову, выглядит join "у нас "

Код: java
1.
2.
3.
4.
5.
QueryBuilder qb = QueryBuilder.select(Employee.class, "e");
qb.addCondition("xxx", false);

qb.addSource(Task.class, "t");
qb.addCondition("e.id = t.employeeId");



как ты любишь говорить, дичь ;) . Хотя все примеры не очень удачные, т.к. достаточно примитивные


Андрей Панфилов
а потом заявить что оппонент в глаза долбится.

я не говорил, что долбишься, но читаешь невнимательно и тут же шашкой махать
...
Рейтинг: 0 / 0
17.07.2020, 13:52
| Ответить | Цитировать | Написать  
Новые веяния
    #39980998
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
chpasha

что происходит тут нужно вкуривать, кто тут на ком стоял
Код: java
1.
2.
3.
  ListJoin<Employee, Task> tasks = employee.join(Employee_.tasks);
   query.select(employee)
        .where(criteriaBuilder.equal(tasks.get(Task_.supervisor), employee.get(Employee_.name)));


а что тут
Код: sql
1.
2.
3.
4.
5.
entityManager.createQuery("""
      select  e from Employee e 
           inner join fetch e.tasks 
      where xxx
"""


понятно сразу много кому
Скажем так: "вкуривать, кто тут на ком стоял" и "понятно сразу много кому" понятия субъективные, и лично мне ни то, ни то совершенно непонятно, однако, уже по вполне объективной причине: то что написано - написано неверно: если мы хотим получить список задач, где исполнитель сам себе супервизор, то нужно брать и выбирать задачи, а не исполнителей, а если мы хотим получить исполнителей, у которых есть задачи, в которых они еще супервизоры - то нужно брать исполнителей, и рисовать in/exists, а не умножать на задачи чтобы еще и ассоциативные связи были битые ( 22150068 ).

Если заходить с другой стороны, то:
- здесь JPQL заработало пол-очка за счет text blocks (или что там у вас вместо 13-й жавы), завтра придут более новые веяния и кто-то решит что интерполяция строк мега крутая тема и обязательно к применению (и пофиг что в разных контекстах оно должно работать по-разному)
- билдер всегда лучше парсера, конкретно в вашем примере если завтра прилетят требования, что нужно накидать условий "в зависимости от фазы луны", то вся эта мнимая "красота" JPQL сведется на нет, а вот CriteriaQuery можно спокойно гонять по стэку, разбирать и обогащать, сложно - это не когда букв много, а когда приходится простые вещи делать через жопу.

chpasha

а вот так, к слову, выглядит join "у нас "

Код: java
1.
2.
3.
4.
5.
QueryBuilder qb = QueryBuilder.select(Employee.class, "e");
qb.addCondition("xxx", false);

qb.addSource(Task.class, "t");
qb.addCondition("e.id = t.employeeId");



как ты любишь говорить, дичь ;) . Хотя все примеры не очень удачные, т.к. достаточно примитивные

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

chpasha

Андрей Панфилов
а потом заявить что оппонент в глаза долбится.

я не говорил, что долбишься, но читаешь невнимательно и тут же шашкой махать

мы как только искоренили JPQL, так сразу количество ошибок резко сократилось, здесь, на мой взгляд, вывод о том что нужно, а что не нужно использовать, совершенно очевидный.
...
Рейтинг: 0 / 0
17.07.2020, 15:38
| Ответить | Цитировать | Написать  
Новые веяния
    #39981014
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Андрей Панфилов
лично мне ни то, ни то совершенно непонятно, однако, уже по вполне объективной причине: то что написано - написано неверно: если мы хотим получить список задач, где исполнитель сам себе супервизор
да это первый попавшийся пример из гугла


Андрей Панфилов
если завтра прилетят требования, что нужно накидать условий

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

Андрей Панфилов
конечно дичь

о чем и спич

Андрей Панфилов
мы как только искоренили JPQL, так сразу количество ошибок резко сократилось
х.з. какие выводы можно сделать по одной истории успеха ;) - мне иногда приходится запускать запрос на выполнение, чтоб допереть какой sql из этой хрени генерится и соотвественно, что хотел сказать автор.
...
Рейтинг: 0 / 0
17.07.2020, 16:24
| Ответить | Цитировать | Написать  
Новые веяния
    #39981020
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
chpasha

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

Много писал SQL.

Но что понимают под словами "разветвленных условий" мне вообще не понятно
"переиспользования кусков" так же не очень понятный термин, никаких проблем с клавишами Ctrl-C, Ctrl-v в моей среде разработки (PL SQL Developer) нет

Нафига нужен какой-то там Criteria API лично мне не понятно. Если нужно сбилдить SQL команду, мне вполне хватает StringBuffer.append + PreparedStatement.set()
/если меняется кол-во параметров на входе, это конечно нужно отслеживать, но чем тут поможет CriteriaAPI мне так же не ясно/

Если речь про интерфейсы типа Query-By-Example (термин Oracle Forms), то они должны делаться один раз на системной уровне (что Oracle Forms, что Oracle ADF) и никого не парят.
...
Рейтинг: 0 / 0
17.07.2020, 16:33
| Ответить | Цитировать | Написать  
Новые веяния
    #39981052
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Leonid Kudryavtsev
Если нужно сбилдить SQL команду, мне вполне хватает StringBuffer.append + PreparedStatement.set()
не хватит:
- фильтры не только в хвосте запроса (where), а еще и в середине (join)
- а еще у джойнов есть алиасы
- а еще у биндов есть имена
- а еще есть подзапросы
- а еще бывает что кто-то добавляет, переименовывает и даже(!) удаляет колонки в таблицах
- а еще хочется чтобы за ввод пользователя, бизнесовые критерии и ограничения ИБ отвечали разные слои

вероятность того, что это можно что-то слепить на каком-нибудь mustache куда выше чем на StringBuffer.append
...
Рейтинг: 0 / 0
17.07.2020, 17:27
| Ответить | Цитировать | Написать  
Новые веяния
    #39981064
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
chpasha
проблема в том, что есть масса запросов, простых как дерево, где он имхо не нужен.

Ну есть и есть. От того что я будут писать:

Код: java
1.
2.
3.
4.
return dao.getList(
        User.class,
        (root, cq, cb) -> cb.equal(root.get(User_.name), "Вася")
);



вместо:

Код: java
1.
2.
3.
TypedQuery<User> query = em.createQuery("select e from User e where e.name = ?1");
query.setParameter(1, "Вася");
return query.getResultList();



Код сложнее не станет, зато станет более устойчивым к изменениям модели
...
Рейтинг: 0 / 0
17.07.2020, 17:39
| Ответить | Цитировать | Написать  
Новые веяния
    #39981072
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Андрей Панфилов

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

Чем?

Андрей Панфилов
Код сложнее не станет

лукавство

1. native SQL-код можно сделать copy-past в PL/SQL девелопер и проверить
2. native SQL-код можно сделать copy-past и перенести во View или PL/SQL на стороне сервера
3. если будет глючить или будут проблемы с перформансом, SQL-код можно сделать Copy-Past и послать админу и надеятся, что админ в ответ не пошлет тебя
4. при необходимости выкинуть "убогую Java" и взять новомодный язык "смешарики 5G". скорее всего, так же, можно будет сделать copy-past и повторно его использовать
и еще 100500 сценариев из реальной жизни
...
Рейтинг: 0 / 0
17.07.2020, 17:57
| Ответить | Цитировать | Написать  
Новые веяния
    #39981074
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
xerxf
Последнее время делаю довольно много code review и замечаю такую вещь - пошло прямо таки какое то повальное увлечение переусложнением кода. Что это - не понимание сути и попытка впихнуть везде, где только можно свежеполученные знания или реальная необходимость, которой я никак не могу проникнуться?
Как пример:
Есть некая функция. которая что то там делает, но основная логика скрыта в вызываемой библиотечной функции. Эта библиотечная функция синхронизированна. И возвращает список. причём эта библиотечная функция в классе-синглтоне.
По логике программы эта функция должна вызываться в цикле несколько раз с разными параметрами. Программист оборачивает функцию в Future, внутри результаты работы библиотечной функции пишет в потокобезопасную коллекцию(причём над коллекцией он тоже сделал обёртку-синглтон), и все эти фьчерсы засылает в CompletableFuture.allOf. А по whenComplete выбирает данные из потокобезопасной коллекции и что то с ними делает. Вопрос - а зачем так сложно? всё равно же всё споткнётся на синхронизированном методе ( а там кроме него по сути и нет ничего) и будет выполняться фактически последовательно, без всякого парралелилизма?

По данному эмоциональному тексту очень сложно судить о том правильно там что-то реализовано или переусложнено.
Всё зависит от ситуации. Возможно ты имеешь дело с плодом рефакторинга. Или код к чему-то готовился. Или из кода
выпиливалось что-то очень крупное и ты видешь ошмётки.

Словом нет хорошего или плохого кода. Есть просто некое бесконечное состояние евро-ремонта в коде и есть
команда программистов которые либо "терпят" этот код либо заводят technical dept и переписывают его.

Идеальный код есть только в наших снах и фантазиях.

Но если ты в состоянии улучшить этот код и при этом не сломать приложение - welcome.

По топику. Не стесняйся публиковать сорцы. Как говорил один любитель пингвинов - Talk is cheep! Show me fucken code!

Разумеется вымарай все бизнесовые идентификаторы.
...
Рейтинг: 0 / 0
17.07.2020, 18:06
| Ответить | Цитировать | Написать  
Новые веяния
    #39981075
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Leonid Kudryavtsev
Андрей Панфилов

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

Чем?
Например перестанет компилироваться если поле убрали/переименовали.

Leonid Kudryavtsev

Андрей Панфилов
Код сложнее не станет

лукавство

1. native SQL-код можно сделать copy-past в PL/SQL девелопер и проверить
2. native SQL-код можно сделать copy-past и перенести во View или PL/SQL на стороне сервера
3. если будет глючить или будут проблемы с перформансом, SQL-код можно сделать Copy-Past и послать админу и надеятся, что админ в ответ не пошлет тебя
4. при необходимости выкинуть "убогую Java" и взять новомодный язык "смешарики 5G". скорее всего, так же, можно будет сделать copy-past и повторно его использовать
и еще 100500 сценариев из реальной жизни


Леонид, вот расскажите-ка два момента:
- в каком месте вы вообще увидели native SQL-код? разговор был про JPQL и Criteria API. JPQL - это нифига не native
- в какое место PL/SQL-девелопера вы собрались вставлять свою (еще ненаписанную) нетленку на стрингбилдерапенд?
...
Рейтинг: 0 / 0
17.07.2020, 18:10
| Ответить | Цитировать | Написать  
Новые веяния
    #39981078
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
xerxf

Или ещё - функция возвращает строку. Эта строка передаётся в другую функцию. Другая функция этой строке что то там ищет. Всё. Зачем первая функция строку оборачивает в Option ? Не, я всё понимаю - функциональщина, защита от null и всё такое.. Но как бы любые лишние телодижения - это лишние тормоза и каждая лишняя строчка - это потенциальный источник проблем (все мы человеки - чем больше напишешь, тем больше вероятость ошибки) зачем это всё? особенно если первая функция гарантированно возвращает не null

Optional может быть полезен когда ты процессишь Stream объектов. Мы это уже обсуждали в форуме.
Найдите сами ссылку.
...
Рейтинг: 0 / 0
17.07.2020, 18:15
| Ответить | Цитировать | Написать  
Новые веяния
    #39981138
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
Андрей Панфилов
Код сложнее не станет

читаемость имхо ниже. Может ты стопицот таких запросов написал и тебе оно кажется одинаковым, я смотрю на то и другое, и что происходит во втором случае понимаю не напрягаясь, в отличие от первого. добавь еще 3-4 джоина с условиями и дело только усугубится

Андрей Панфилов
более устойчивым к изменениям модели

так-то да, но на практике преимущество имхо минимальное. даже если отвлечься от того, что IDEA например умеет поля в jql/hql запросах рефакторить, ну как долго проживет такой баг с изменившейся моделью, до первого запуска тестов?

Leonid Kudryavtsev
"переиспользования кусков" так же не очень понятный термин, никаких проблем с клавишами Ctrl-C, Ctrl-v
ну если недостатки ctrl-c, ctrl-v неочевидны, то ок, никаких проблем нет.
...
Рейтинг: 0 / 0
17.07.2020, 22:35
| Ответить | Цитировать | Написать  
Новые веяния
    #39981212
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
А разве компилятор не упадет если модель поменял а хкл жпкл запрос забыл? По-моему все тоже попадает.
...
Рейтинг: 0 / 0
18.07.2020, 09:27
| Ответить | Цитировать | Написать  
Новые веяния
    #39981213
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
Где-то в степи
Пардон за офтоп
ребята есть ли кто живой из ЦРПТ по табачному направлению, жутко нужна консультация
зы Топик популярный

Ты ничего не перепутал?
...
Рейтинг: 0 / 0
18.07.2020, 09:30
| Ответить | Цитировать | Написать  
Новые веяния
    #39981218
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
andreykaT,
Ну а че нет, на подножке проехать,
Вам же не лень, вместо того что бы пройти дальше, тут мне тыкать ))
...
Рейтинг: 0 / 0
18.07.2020, 10:24
| Ответить | Цитировать | Написать  
Новые веяния
    #39981283
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
andreykaT
А разве компилятор не упадет если модель поменял а хкл жпкл запрос забыл?
нет конечно, это же строка. парсит ее хибер в рантайме, а не компилятор. Тоже самое касается синтаксически неправильно составленного запроса. IDEA может ругаться и рефакторинг поддерживает, но это очень тонкий лед, ни разу не замена тестам.
...
Рейтинг: 0 / 0
18.07.2020, 14:46
| Ответить | Цитировать | Написать  
Новые веяния
    #39981351
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
chpasha
Участник
автоинкремент в качестве id уже видал?
...
Рейтинг: 0 / 0
18.07.2020, 18:58
| Ответить | Цитировать | Написать  
Новые веяния
    #39981355
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
chpasha
andreykaT
А разве компилятор не упадет если модель поменял а хкл жпкл запрос забыл?
нет конечно, это же строка. парсит ее хибер в рантайме, а не компилятор. Тоже самое касается синтаксически неправильно составленного запроса. IDEA может ругаться и рефакторинг поддерживает, но это очень тонкий лед, ни разу не замена тестам.

да неее.. спринг дата JPQL - точно падает если модель меняется. правда, там сами запросы внутри аннотаций. может спринг дата такой умный. забыл детали уже.
...
Рейтинг: 0 / 0
18.07.2020, 19:06
| Ответить | Цитировать | Написать  
Новые веяния
    #39981356
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
Где-то в степи
andreykaT,
Ну а че нет, на подножке проехать,
Вам же не лень, вместо того что бы пройти дальше, тут мне тыкать ))

ну я просто когда то давно имел время общения и работы с ними. поэтому и заинтересовался ))) какое они отношение имеют к топику.
...
Рейтинг: 0 / 0
18.07.2020, 19:08
| Ответить | Цитировать | Написать  
25 сообщений из 79, страница 2 из 4
  2  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Новые веяния
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&startmsg=39980781&tid=2120737]:
 0ms
get settings:
 20ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 46ms
get topic data:
 13ms
get forum data:
 2ms
get page messages:
 525ms
get tp. blocked users:
 2ms
others: 13ms
total:  642ms
созд. / загр.: 642ms
x
x
Закрыть


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