@ElementCollection Vs @OneToMany

[neverkas]

Buenas, estaba practicando el parcial QueMePongo y me había surgido dudas sobre @ElementCollection.

Entiendo que @ElementCollection se usa para definir una relación @OneToMany de Objetos simples como Strings, ..., Enums (si no me equivoco, Value Objects) y también para clases que son @Embeddable

Mi dudas serían

1. En el caso planteado genera una tabla como si hubiese definido el @onetomany (suponiendo que colocaba @Entity en vez de @Embeddable en Color) excepto que no podría definir el cascadeType y fetchType ?
2. Las clases que definimos con @embeddable son justo aquellas que no queremos persistir, por tanto figurarían en el modelo físico, pero si se guarda una referencia de estas + @ElementCollection haría lo contrario de la definición de @embeddable ? (el no crear una tabla por esa clase, y que todos los atributos se integren a la clase que se guarda referencia)

@Entity
@Table(name="prendas")
class Prenda{
   @Id @GeneratedValue
    Long id;

    // - Como sólo nos interesa el valor, es una colección de "value objects"
    // - Define una relación @OneToMany donde una prenda puede tener muchos colores
    // pero Color es un Embeddable
    @ElementCollection
    List<Color> colores = new ArrayList<Color>();

    @Enumerated(EnumType.STRING)
    Categoria categoria;

    String descripcion;
}

// - avisamos que esta clase se va a embeber dentro de otra clase
// - todos los atributos estarán en otra, no se creará una tabla
// aunque como en Prenda usamos @ElementCollection se creará la tabla
// como un @OneToMany
@Embeddable
class Color{
    @Column(name="color_nombre");
    String color;
    @Column(name="color_codigo");
    String codigoHexa;
}

// En la definición de los Enum no requieren annotations
Enum CategoriaPrenda{
    ARRIBA, ABAJO, ENTEROS, CALZADOS, ACCESORIOS;

    boolean cubreTemperatura(temperatura){
        // ...
    }
}

Gracias,

[neverkas]

También tenía una última duda, la agrego como otra respuesta para que no quede muy extenso.

Tenía dudas en el DER respecto a si debería existir la relación(Evento, Sugerencia) de 1 a N,
ví que en la resolución aparece, pero como en Evento es un método el que devuelve la lista y no un atributo,
sería válido si agregara el atributo en Sugerencia ?

@Entity
@Table(name="sugerencias")
class Sugerencia{
    @OneToMany
    List<Prenda> prendas = new ArrayList<Prenda>();

    @ManyToOne
    Evento evento;
}

Caso contrario me quedaría de la siguiente forma

[gastonprieto]

En el caso planteado genera una tabla como si hubiese definido el @onetomany (suponiendo que colocaba @entity en vez de @embeddable en Color) excepto que no podría definir el cascadeType y fetchType ?

si, pero además esto te va a afectar en los updates que tiene que borrar todos los elementos y luego insertarlos, porque no mantiene una identidad ese value object (por lo que recuerdo).

Las clases que definimos con @embeddable son justo aquellas que no queremos persistir

No es que no las quierar persistir (muy importante), sino que no te importa/no queres manejar su identidad. Entonces por ejemplo si tenes una relacion toOne podrías unirla a la tabla original, un beneficio a nivel joins

Tenía dudas en el DER respecto a si debería existir la relación(Evento, Sugerencia) de 1 a N,

Ojo que la relacion entre evento y sugerencia recien aparece en la 2da parte, originalmente, no hay ninguna relación entre ellos. Por eso en el diagrama de clases original dice que es un mensaje.

En base al planteamiento de la 2da parte tenes que analizar que te conviene.

[neverkas]

Buenas profe,

1. Ahí me quedó mas claro ese punto
2. Claro, entonces los trataríamos como value objects, no? Pasan a formar parte de la identidad de donde son embebidos
3. Genial, me había entrado la duda al comparar con la resolución, no me di cuenta

Gracias,