Хранение хеша как байтового массива с JPA

Question

Мой User класс сущности содержит поле хеша пароля, которое представляет собой байтовый массив фиксированной длины (32, поскольку это хеш SHA-256).

@Entity
public class User {
    @Column(nullable=false)
    private byte[] passwordHash;
    ...
}

Как видите, я не аннотировал это чем-то особенным, просто NOT NULL.

Это работает, но будет ли оно работать? Моя схема сгенерирована Hibernate, но я не знаю точно, что она генерирует (в настоящее время я использую базу данных HSQL в памяти).

Я обеспокоен тем, что, поскольку он не знает, что это массив фиксированной длины (поле length аннотации Column относится только к строкам), он будет хранить этот хеш в поле BLOB, которое добавлен в запись в качестве указателя (если я правильно понимаю, как работают базы данных).

Это правда, и как я могу изменить это? Должен ли я просто закодировать хеш как строку, с base64 или hex, принимая это влияние на производительность / правильность?

Answer 1

Я обеспокоен тем, что, поскольку он не знает, что это массив фиксированной длины (поле длины аннотации Column применяется только к строкам), (...)

Если вы укажете длину столбца, Hibernate будет использовать эту информацию для определения типа столбца SQL для генерации (TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB).

Что мне нужно, так это BINARY (32)

Вы пробовали это?

@Column(columnDefinition="BINARY(32) NOT NULL")
private byte[] passwordHash;

Answer 2

tinyblob - хорошее сочетание ( справочник по типам mysql ), но все мои приложения работают со строками.Если вы действительно заботитесь о миллисекундах, попробуйте обе версии в профилировщике и посмотрите, что работает лучше всего.Мой предпочтительный профилировщик - тот, который включен в netbeans.

Answer 3

Это может быть не так эффективно, но я предлагаю вам использовать String в качестве типа хранилища и переводить по мере необходимости методами getter и setter. Это обеспечивает максимальную переносимость JPA между различными базами данных.

Я использую аналогичную технику с датой / временем, сохраняя длинные значения, которые представляют время с начала эпохи в UTC, что позволяет мне избежать проблем с часовым поясом (информация о часовом поясе не переносима в датах базы данных во всех базах данных).

Answer 4

Насколько мне известно, хеш SHA-256 всегда содержит только печатаемые символы (и, если нет, кодирует его base64), поэтому решение состоит в том, что вы МОЖЕТЕ сохранить его как строку, а затем использовать поле length поляColumn аннотация.

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