Imagine las siguientes dos entidades. Element
es la clase simple que contiene algunos datos:JPA - entidad "versionada", se necesita asesoramiento de diseño
@Entity
public class Element {
private String data;
public String getData() { return data; }
public void setData(String data) { this.data = data; }
}
La siguiente clase, llamada VersionedElement
, se extiende Element
y contiene diferentes versiones a lo largo de la versión actual. Aquí está mi "solución":
@Entity
public class VersionedElement extends Element {
private Set<Element> versions;
private Element currentVersion;
@Override
public String getData() {
return getCurrentVersion().getData();
}
@Override
public void setData(String data) {
getCurrentVersion().setData(data);
}
@OneToMany
public Set<Element> getVersions() {
return versions;
}
public void setVersions(Set<Element> versions) {
this.versions = versions;
}
@ManyToOne
public Element getCurrentVersion() {
return currentVersion;
}
public void setCurrentVersion(Element currentVersion) {
this.currentVersion = currentVersion;
}
}
Y no me gusta lo que he escrito, algo malo en ello, el enfoque demasiado sencillo. En primer lugar, en la última clase currentVersion
no está limitado por y no tiene relación con versions
. Parece que el código carece de algunas clases de ayuda, o nivel de abstracción, o técnica de anotación JPA, o todo lo anterior. Necesito una solución manual elegante, digna de JPA para este caso simple. Cualquier sugerencia, enlace o fragmento de código sería apreciado.
¿no es suVersion actual la "presente" instancia? – ThomasRS
@Thomas, muy buena pregunta, ¿qué pasa con los ids en este caso, especialmente al cambiar la versión actual? No lo sé. Tal vez las clases necesitan ser reescritas, los datos tomados como clases separadas, etc. Pero diferentes datos deben tener diferentes identificadores, eso es seguro. Estoy un poco confundido, esperaba "enterrar tu código, hacer eso y eso, así es como solía hacerse, es un patrón común". No puedo creer que nadie haya hecho eso ya. – Osw