Hola Diego,
Gracias por la aclaración respecto de las claves compuestas mapeadas
de esa manera. Me había surgido la duda porque había leído que la
clave compuesta debía ser serializable, por tanto tenia que procurar
que esa entidad no tenga tipos no serializables. Entendí tu punto de
todas maneras y me aclaró un poco mas el panoráma.
Composite-id Serializables
http://nhforge.org/doc/nh/en/index.html#mapping-declaration-compositeid
Finalmente, y leyendo mas en la documentación de NH le encontré la
vuelta a posibles alternativas que plantean frente a estas claves
compuestas. Lo que hice fué manejar las colecciones de hijos
manualmente en el momento de hacer el Save() o Opdate() del padre,
basándome en la documentación
http://nhforge.org/doc/nh/en/index.html#example-parentchild-update
En mi caso, dejé el unsaved-value de la clave compuesta del hijo en su
valor por defecto ("none") y en el Update() del padre, persisto
entidades hijos que sean nuevas y luego hago el Update() del padre. De
esa manera me funcionó tanto el Save() como el Update().
Aún no terminé de repasar todo el proyecto con esta alternativa asi
que si surge algo nuevo lo comento por acá. Te agradezco mucho tu
predisposición y la información que siempre es bienvenida.
Saludos,
Matias.-
On 19 mayo, 01:18, Diego Mijelshon <[email protected]> wrote:
> Matias,
>
> Los many-to-one son lazy por defecto, por lo que ninguna de tus
> preocupaciones aplica.
>
> Diego
>
> 2010/5/18 Matias Veleda <[email protected]>
>
>
>
> > Hola Diego,
>
> > antes que nada gracias por tu ayuda. Quería comentarte lo siguiente
> > respecto a mapear la clave de esa manera que me anduvo dando vueltas.
> > En este caso la entidad Actividad tiene bastantes colecciones y
> > propiedades y como ese ejemplo hay otros dentro de la aplicación. Mi
> > pregunta es la siguiente, no sería demasiada información a retener
> > dentro de una clave compuesta? No sería mejor tenes los datos
> > primitivos necesarios para armar la clave? De esa manera mi ObjetivoId
> > tendría internamente una referencia a la Actividad, y solamente para
> > tener el Id del Objetivo, estaría levantando mucha información que no
> > es necesaria. Y otra cosa que tenia duda que no se si es correcto, es
> > que en las documentaciones proponen que las claves compuestas sean
> > serializables; si mi entidad Actividad en este caso, tiene colecciones
> > del tipo IList, estas no serían serializables.
> > Es muy errado lo que estoy planteando? Es algo para tener en cuenta?
> > Gracias!
>
> > Saludos,
>
> > Matias.-
>
> > On 18 mayo, 10:54, Diego Mijelshon <[email protected]> wrote:
> > > El primer problema que tienes es que el Id de Objetivo no está
> > especificando
> > > la foreign key que posee.
> > > Yo la declararía así:
>
> > > <composite-id name="Id" class="ObjetivoId">
> > > <key-many-to-one name="Actividad">
> > > <column name="ID_PROGRAMA" sql-type="VARCHAR2(10)" />
> > > <column name="ID_ACTIVIDAD" sql-type="VARCHAR2(10)" />
> > > </key-many-to-one>
> > > <key-property name="IdObjetivo" length="10">
> > > <column name="ID_OBJETIVO" sql-type="VARCHAR2(10)" />
> > > </key-property>
> > > </composite-id>
>
> > > Y, por supuesto, reemplazas las propiedades sueltas con una referencia a
> > > Actividad que debes asignar antes de grabar.
> > > Empieza con eso y vemos qué sucede.
>
> > > Diego
>
> > > 2010/5/18 Matias Veleda <[email protected]>
>
> > > > Hola Diego,
>
> > > > Acá te dejo parte del mapping que me ha traido problemas:
>
> > > > <class name="Actividad" table="M4_ACTIVIDADES">
>
> > > > <composite-id name="Id" class="ActividadId">
> > > > <key-property name="IdPrograma" length="10">
> > > > <column name="ID_PROGRAMA"
> > > > sql-type="VARCHAR2(10)" />
> > > > </key-property>
> > > > <key-property name="IdActividad" length="10">
> > > > <column name="ID_ACTIVIDAD"
> > > > sql-type="VARCHAR2(10)" />
> > > > </key-property>
> > > > </composite-id>
>
> > > > ...
>
> > > > <bag name="ListaObjetivos"
> > table="M4_ACTIVIDADES_OBJETIVOS"
> > > > lazy="true" cascade="all-delete-orphan" inverse="true">
> > > > <key>
> > > > <column name="ID_PROGRAMA"/>
> > > > <column name="ID_ACTIVIDAD"/>
> > > > </key>
> > > > <one-to-many class="Objetivo"/>
> > > > </bag>
>
> > > > ...
> > > > </class>
>
> > > > <class name="Objetivo" table="M4_ACTIVIDADES_OBJETIVOS">
>
> > > > <composite-id name="Id" class="ObjetivoId">
> > > > <key-property name="IdPrograma" length="10">
> > > > <column name="ID_PROGRAMA"
> > > > sql-type="VARCHAR2(10)" />
> > > > </key-property>
> > > > <key-property name="IdActividad" length="10">
> > > > <column name="ID_ACTIVIDAD"
> > > > sql-type="VARCHAR2(10)" />
> > > > </key-property>
> > > > <key-property name="IdObjetivo" length="10">
> > > > <column name="ID_OBJETIVO"
> > > > sql-type="VARCHAR2(10)" />
> > > > </key-property>
> > > > </composite-id>
>
> > > > <property name="NombreEsp">
> > > > <column name="N_OBJETIVO_ESP" length="100"
> > > > sql-type="VARCHAR2(100)"/
>
> > > > </property>
>
> > > > ...
>
> > > > </class>
>
> > > > En este caso, la Actividad la persiste sin problemas, sea un caso o el
> > > > otro pero al llegar a la colección de Objetivos no puede determinar
> > > > qué debe hacer con cada uno. Desde ya muchas gracias.
>
> > > > Saludos,
>
> > > > Matias.-
>
> > > > On 18 mayo, 08:25, Diego Mijelshon <[email protected]> wrote:
> > > > > Matías,
> > > > > Mandá un ejemplo de clase padre e hijo con sus mappings con los que
> > > > tengas
> > > > > problemas.
>
> > > > > Diego
>
> > > > > 2010/5/18 Matias Veleda <[email protected]>
>
> > > > > > Hola,
>
> > > > > > Les cuento la situación en la que me encuentro a ver si pueden
> > > > > > ayudarme o guiarme un poco en la solución. Tengo una aplicación que
> > > > > > tiene que lidiar con una base de datos ya diseñada y en
> > funcionamiento
> > > > > > desde hace rato. No tengo demasiada autonomía sobre la BD ya que
> > > > > > además es usada y administrada por otras aplicaciones como META4
> > por
> > > > > > ejemplo.
> > > > > > El tema en este caso son las claves compuestas. Se que no es
> > > > > > recomendado utilizarlas y que de alguna manera es alejarse del
> > diseño
> > > > > > de objetos y acercarse al diseño de bases de datos, pero en este
> > caso
> > > > > > (y contra mi voluntad) digamos que tengo que respetar estas claves
> > > > > > compuestas.
> > > > > > El problema se presenta en qué NH no se da cuenta cuando es una
> > > > > > inserción o cuando es una actualización, de manera que, después de
> > > > > > investigar un poco en internet buscando alternativas encontré que
> > la
> > > > > > mayoria proponen diferenciar a mano si es un Update() o un Save().
> > > > > > Ahora bien, algunas entidades obviamente funcionaron bien, pero me
> > > > > > pasa que cuando tengo entidades padre (cuya clave es compuesta) que
> > > > > > tienen hijos (cuyas claves son compuestas también) que al querer
> > > > > > persistir los hijos me da error, al parecer porque no puede
> > > > > > identificar si debe hacer un Update() o un Save() con ellos. Es
> > decir,
> > > > > > el padre lo podría persistir correctamente pero al llegar a los
> > hijos
> > > > > > falla.
> > > > > > A alguno le ha tocado lidiar con este tema? Y si es asi, qué
> > > > > > soluciones encontraron? Una posible solución podría ser eliminar
> > los
> > > > > > Cascades y realizar el mismo mecanismo manual con los hijos, es
> > decir,
> > > > > > verificar si existen ya en la BD, y determinar si es Update() o
> > > > > > Save(). Esto calculo va a funcionar pero por ahi hay alternativas
> > > > > > mejores.
>
> > > > > > Perdón lo extenso del planteo, y si algo no quedó claro me dicen e
> > > > > > intento explicarlo mejor. Desde ya muchas gracias por cualquier
> > dato
> > > > > > que me puedan compartir para darle una solución viable a este tema.
>
> > > > > > Saludos,
>
> > > > > > Matias.-
>
> > > > > > --
> > > > > > Para escribir al Grupo, hágalo a esta dirección:
> > > > > > [email protected]
> > > > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > > > > --
> > > > > Para escribir al Grupo, hágalo a esta dirección:
> > > > [email protected]
> > > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > > > --
> > > > Para escribir al Grupo, hágalo a esta dirección:
> > > > [email protected]
> > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > > --
> > > Para escribir al Grupo, hágalo a esta dirección:
> > [email protected]
> > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > --
> > Para escribir al Grupo, hágalo a esta dirección:
> > [email protected]
> > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> --
> Para escribir al Grupo, hágalo a esta dirección:
> [email protected]
> Para más, visite:http://groups.google.com/group/NHibernate-Hispano
--
Para escribir al Grupo, hágalo a esta dirección:
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
