Получить нетерпеливо коллекцию сущностей, содержащих другие нетерпеливо полученные коллекции - PullRequest
1 голос
/ 27 октября 2011

Я застрял в отношении M: N между сущностью и строками. Пользователь может иметь более одной роли, и каждая роль может быть назначена более чем одному пользователю. Роль это просто строка. Роли содержатся в таблице с двумя столбцами: roleId и roleName.

Я создал две сущности, но я абсолютно не в состоянии заставить это работать. Первый объект - пользователь:

@Entity
@Table(name="appUsers")
public class UserEntity {
    @Id
    private String login;
    private String password;
    @OneToMany(fetch=FetchType.EAGER,mappedBy="user") //we always need to load user's roles
    private Collection<UsersToRoles> roles;
    @Transient
    private Collection<String> roleNames;

    public String getLogin() {
        return login;
    }

    public String getPassword() {
        return password;
    }

    @PostLoad
    void prepareRoleNames() {
        roleNames = new HashSet<String>(roles.size());
        for (UsersToRoles mapping : roles)
            roleNames.add(mapping.getNameOfRole());
    }

    public Collection<String> getRoles() {
        return roleNames;
    }
}

Вторым является объект, связанный с соединительной таблицей:

@Entity
@IdClass(UsersToRolesId.class)
public class UsersToRoles {
    @Id
    @SuppressWarnings("unused")
    @Column(name="login")
    private String login;
    @Id
    @SuppressWarnings("unused")
    @Column(name="roleId")
    private int roleId;
    @ElementCollection(fetch=FetchType.EAGER)
    @CollectionTable(name="userRoles", joinColumns={@JoinColumn(name="roleId")})
    private List<String> roleName;
    @ManyToOne
    @JoinColumn(name="login")
    @SuppressWarnings("unused")
    private UserEntity user;

    public String getNameOfRole() {
        if (roleName.isEmpty())
            throw new CommonError("Role name for roleId=" + roleId, AppErrors.ACCESSOR_UNAVAILABLE);
        return roleName.get(0);
    }
}

class UsersToRolesId {
    private String login;
    private int roleId;

    /**
     * Implicit constructor is not public. We have to
     * declare public non-parametric constructor manually.
     */
    public UsersToRolesId() {
    }

    @Override
    public int hashCode() {
        return 17*login.hashCode() + 37*roleId;
    }

    @Override
    public boolean equals(Object obj) {
        if (!(obj instanceof UsersToRolesId))
            return false;
        UsersToRolesId ref = (UsersToRolesId)obj;
        return (this.login.equals(ref.login) && this.roleId == ref.roleId);
    }
}

И проблема в том, что коллекция roleName всегда равна нулю. Я не могу заставить его работать. Когда я делаю ошибку в имени таблицы в аннотации @CollectionTable, она все равно работает. JPA вообще не получает подколлекцию. Это делает выбор из таблицы пользователя, объединенного с таблицей UsersToRoles, но соединение с таблицей userRoles отсутствует.

Могу ли я когда-нибудь это сделать? Могу ли я получить коллекцию сущностей, в которой содержатся другие коллекции?

Ответы [ 2 ]

1 голос
/ 27 октября 2011

Ваше отображение совершенно неверно. UsersToRoles имеет столбец roleId. Таким образом, это относится к одной роли. Как это могло иметь коллекцию имен ролей? Столбец входа в систему дважды отображается в сущности. Более того, для меня это выглядит как простая таблица соединений без каких-либо других атрибутов, кроме roleId и login, которые являются внешними ключами идентификаторов User и Role соответственно.

У вас должно быть две сущности: User и Role с ассоциацией ManyToMany, использующей таблицу UsersToRoles в качестве таблицы соединения. Вот и все. Таблица UsersToRoles не должна отображаться как сущность: это чистая таблица соединений.

1 голос
/ 27 октября 2011

JPA-провайдеры обычно имеют свойство конфигурации, обозначающее глубину активной выборки по умолчанию, т. Е. hibernate.max_fetch_depth для Hibernate. Проверьте, видите ли вы больше, когда увеличиваете его.

Кроме того, подумайте о своем дизайне. Извлечение вложенных коллекций из коллекции может быть хорошей идеей только в ограниченных сценариях (с точки зрения производительности). Когда вы так аннотируете свою сущность, вы будете использовать выборку во всех случаях. Возможно, вам было бы лучше с "ленивым" и с нетерпением извлекать его только с явным запросом с предложением JOIN FETCH?

...