JPA полиморфные отношения, статическая и динамическая типизация - PullRequest
Новая
       26

JPA полиморфные отношения, статическая и динамическая типизация

0 голосов
/ 08 января 2012

Я пытаюсь реализовать довольно сложное отображение в JPA. Мне нужно что-то похожее на этот пример. Существует несколько видов писателей и несколько видов писаний. Каждое письмо должно иметь постоянное поле автора. Неважно, динамический тип автора. Вот почему я установил статический абстрактный тип. Однако автор должен иметь два списка, в которых указаны романы и стихи, которые написал каждый.

Я получаю сообщения о том, что не могу использовать MappedSuperClass в качестве цели для сохраняемого поля. Кто-нибудь знает, как выполнить то, что я пытаюсь сделать?

Я также хочу, чтобы писатель владел этими двунаправленными отношениями. так что на карте должно быть на стороне романа или стихотворения. Однако, похоже, что сопоставленный может быть только на стороне OneToMany .... Это не похоже на странный случай, когда одна вещь владеет многими вещами ... почему я не могу сделать это ...

Большое спасибо за помощь 

@MappedSuperclass
@Access(AccessType.PROPERTY)
public abstract class AbstractWriter implements Serializable{

    private Long id;
    private String name;
    private String email;

    private ArrayList<Novel> novels;
    private ArrayList<Poem> poems;


    @OneToMany(mappedBy="author")
    public ArrayList<Novel> getNovels() {
        return novels;
    }
    public void setNovels(ArrayList<Novel> novels) {
        this.novels = novels;
    }

    @OneToMany(mappedBy="author")
    public ArrayList<Poems> getPoems() {
        return poems;
    }
    public void setPoems(ArrayList<Poem> poems) {
        this.poems = poems;
    }

    @Column(nullable=false)
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }

    @Id @GeneratedValue(strategy= GenerationType.AUTO)
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }
}


@Entity
public class ProfessionalWriter extends AbstractWriter { 
}

@Entity
public class StudentWriter extends AbstractWriter { 
}


@MappedSuperclass
public abstract class AbstractWriting implements Serializable{

    private Long id;

    private String title;
    private AbstractWriter author;
    private byte[] words;




    @ManyToOne
    public AbstractWriter getAuthor() {
        return author;
    }
    public void setAuthor(AbstractWriter author) {
        this.author = author;
    }

    @Id @GeneratedValue(strategy= GenerationType.AUTO)
    public Long getId() {
        return id;
    }
    public void setId(Long id) {
        this.id = id;
    }

    @Lob
    public byte[] getWords() {
        return words;
    }
    public void setWords(byte[] words) {
        this.words = words;
    }

    @Column(nullable=false)
    public String getTitle() {
        return title;
    }
    public void setTitle(String title) {
        this.title = title;
    }
}

@Entity
public class Novel extends AbstractWriting {
}

@Entity
public class Poem extends AbstractWriting {
}

1 Ответ

1 голос
/ 08 января 2012

Абстрактные классы должны быть аннотированы @Entity, а не @MappedSuperclass. И, конечно, вы должны выбрать стратегию наследования .

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

Кроме того, вы не должны использовать ArrayList, а List. EclipseLink будет использовать собственную реализацию List для поддержки отложенной загрузки, каскадов и т. Д. И кстати, рекомендуется программировать на интерфейсы, а не на реализации.

...