Симплекс Совтвер: разработка ПО

суббота, 15 июля 2017 г.

Путаница с компонентом PasswordTextField в Wicket Framework

В нашем проекте используется Wicket Framework (восьмая версия).

Раньше для ввода/редактирования пароля в форме использовался компонент RequiredTextField , сейчас для большей безопасности решили использовать PasswordTextField.

,при использовании компонента PasswordTextField в странице изменения профиля , возникла ошибка: , пароль стал удаляться из базы данных при загрузке страницы.
При этом мы не пароль нигде не удаляли.
После продолжительных поисков решение проблеммы нашлось:
PasswordTextField удаляет пароль из модели.

/** * Overriden to nullify the password. */@Overrideprotected void onDetach()
{
   if (resetPassword) {
      clearInput();

      if (getModel() != null) {
         getModel().setObject(null);
      }
   }

   super.onDetach();
}

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

суббота, 17 июня 2017 г.

flyway и spring: исправление чексумм

У нас базы данных в приложениях обновляется через flyway.

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

Сначала мы просто отключили валидацию

<bean id="flyway" class="org.flywaydb.core.Flyway"

                                    init-method="migrate" >
    <property name="baselineOnMigrate" value="true" />
    <property name="locations" value="classpath:/migrations/" />
    <property name="dataSource" ref="dataSource" />
    <property name="validateOnMigrate" value="false" />
</bean>

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

 мы один раз запустили приложение с исправлением чексумм

<bean id="flyway" class="org.flywaydb.core.Flyway" init-method="repair" >
    <property name="baselineOnMigrate" value="true" />
    <property name="locations" value="classpath:/migrations/" />
    <property name="dataSource" ref="dataSource" />
    <property name="validateOnMigrate" value="false" />
</bean>

Всё, теперь, после одного прогона можно опять включать валидацию.

вторник, 25 апреля 2017 г.

Полиморфные запросы в HQL

Ситуация:

Имеется суперкласс и несколько его наследников, которые в свою очередь содержат в себе другие объекты (разных типов) с каким-нибудь важным значением (например с датой). Необходимо провести поиск по этому значению. Ваш HQL запрос скорее всего будет выглядеть так:

from Parent
where
    Parent.ValueContainerA.valueName > :someValue
    or
    Parent.ValueContainerB.anotherValueName > :someValue)

Проблема:

Для правильного SQL запроса необходимы два left-join между таблицами Parent, ValueContainerA и ValueContainerB. Нужно чтобы HQL протранслировался в следующее:

SELECT...
FROM Parent
    CROSS JOIN ValueContainerA
    CROSS JOIN ValueContainerB
WHERE
    Parent.ValueContainerA_id = ValueContainerA.id
    OR
    Parent.ValueContainerB_id = ValueContainerB.id

В нашем HQL запросе join делается неявно, и по умолчанию хибернейт среди типов join выбирает inner join, а значит он протранслирует HQL в это:

SELECT ...
FROM Parent
    CROSS JOIN ValueContainerA
    CROSS JOIN ValueContainerB
WHERE
    Parent.ValueContainerA_id = ValueContainerA.id
    AND
    Parent.ValueContainerB_id = ValueContainerB.id

Вместо OR получится AND. Такое условие не сможет быть выполнено, и поэтому в результате найдется 0 строк

Решение:

Указать left join явно:

from Parent
    left join ValueContainerA
    left join ValueContainerB
where
    ValueContainerA.valueName > :someValue
    or
    ValueContainer.B.anotherValueName > :someValue

суббота, 10 декабря 2016 г.

Wicket и Websockets.

Понадобилось обновлять страницу посетителя сайта при наступлении события н сервере.

суббота, 15 июля 2017 г.