Estoy trabajando con un esquema existente que prefiero no cambiar. El esquema tiene una relación uno-a-uno entre las tablas Person y VitalStats, donde Person tiene una clave principal y VitalStats usa el mismo campo que su clave principal y su clave foránea para Person, lo que significa que su valor es el valor de la PK correspondiente. de Persona.JPA @OneToOne con identificación compartida: ¿puedo hacerlo mejor?
Estos registros se crean mediante procesos externos, y mi código JPA nunca necesita actualizar VitalStats. Por mi modelo de objetos Me gustaría que mi clase Persona para contener un miembro VitalStats, PERO:
Cuando intento
@Entity
public class Person{
private long id;
@Id
public long getId(){ return id; }
private VitalStats vs;
@OneToOne(mappedBy = “person”)
public VitalStats getVs() { return vs; }
}
@Entity
public class VitalStats{
private Person person;
@OneToOne
public Person getPerson() { return person; }
}
tengo el problema de que carece de un VitalStats @Id, que no funciona para un @Entity. \
Si intento
@Id @OneToOne
public Person getPerson() { return person; }
que resuelve el problema @Id pero requiere que la persona sea serializable. Volveremos sobre eso.
Podría hacer VitalStats @Embeddable y conectarlo a Person a través de @ElementCollection, pero luego tendría que accederse como una colección, aunque sé que solo hay un elemento. Doable, pero a la vez un poco molesto y un poco confuso.
¿Qué me impide decir que la persona implementa Serializable? Nada, en realidad, excepto que me gusta que todo en mi código esté allí por una razón, y no puedo ver ninguna lógica en esto, lo que hace que mi código sea menos legible.
Mientras tanto, simplemente reemplacé el campo Persona en VitalStats con una ID de persona larga e hice esa Id. De VitalStats, por lo que ahora funciona @OneToOne.
Todas estas soluciones a lo que parece (a mí) como un problema directo son un poco torpes, entonces me pregunto si me falta algo, o si alguien puede explicarme por qué Person tiene que ser Serializable
TIA
Gracias, pero me temo que esto no realmente ayuda Has añadido un campo de identificación en VitalStats además del campo Persona, mientras que no puedo agregar un nuevo campo al esquema y tengo que usar el FK que subyace a 'persona' como PK de VitalStats. Ese fue todo el punto. – Michael
No es necesario agregar otra columna debido a la anotación MapById en el atributo persona. El ejemplo que publiqué no era muy claro, modifico el ejemplo para agregar más detalles a VitalStats (vea #JoinColumn en el atributo de persona). Agrego la tabla de base de datos VitalStats y Person y puede ver que la tabla VitalStats contiene solo un PK que es el FK por persona. Creo que es lo mismo que lo que quieres? Si no es lo que quieres, ¿puedes agregar más detalles sobre el diseño de la mesa? @MapId tiene la ventaja de que la entidad persona no necesita ser serializable. Actualicé el ejemplo. –
¡Eso es excelente, gracias! Lo intenté y funcionó. – Michael