tiene sentido, en el session.Save NH siempre considera que tiene que flushear, por un tema de cascades, etc...session.Update lo que hace es un reattach de la entidad a la session, si no detecta ningun cambio...entonces el Update no va a provocar un flush automatico
Gustavo. 2008/9/8 Carlos Peix <[EMAIL PROTECTED]> > Hola Gustavo, > > Me quedo mas tranquilo entonces, justamente el cambio que hice fue ese, le > puse el defaultFlushMode en Commint, antes estaba en Auto y no me hacia el > flush en el commit (creo). Lo que me confundio es que si lo hacia cuando > hacia un session.Save pero no cuando hacia un session.Update. Esto tiene > sentido? > > Carlos Peix > > ------------------------------ > *De:* [email protected] [mailto: > [EMAIL PROTECTED] *En nombre de *Gustavo Ringel > *Enviado el:* Lunes, 08 de Septiembre de 2008 11:08 a.m. > > *Para:* [email protected] > *Asunto:* [NHibernate-Hispano] Re: Pertsistiendo un miembro derivado > > Carlos, yo uso NH Facility con ATM. > > Lo que tengo es definido defaultFlushMode = "Commit" > > y el flush se hace automatico en cada commit (todos los methodos que > trabajan contra la base de datos estan marcados con [Transaction]) > > Hay algunos casos especiales donde hago Delete que tengo que hacer un > session.Flush inmediato...Fabio me habia comentado algo de que si usara hilo > no tendria que hacerlo, pero es en un proyecto empezado y ta...asi funciona. > > Abrazo. > > Gustavo. > > 2008/9/8 Carlos Peix <[EMAIL PROTECTED]> > >> Dario, esa es la primera que se me ocurrio, de hecho es la que use hasta >> ahora que me decidi a hacerlo bien. >> >> De todas maneras tengo otros problemas, creo que NHibernateIntegration >> facility me esta jugando una mala pasada con el flush de la sesion. Alguien >> la usa por aqui junto con el Automatic Transaction Facility? como manejan el >> flush? >> >> Volviendo al tema principal, creo que lo resolvi con IUserType, pero no es >> facil implementarlo cuando la propiedad es un reference type (Object) y >> encima de type desconocido. Los ejemplos que se encuentran en la web manejan >> strings, la cual tiene varias ventajas: es inmutable y sobrecarga Equals. Si >> no dispones de eso hacer un IUserType no es trivial. >> >> Por lo demas, es la solucion perfecta. >> >> Ya pasare el codigo. >> >> Carlos Peix >> >> ------------------------------ >> *De:* [email protected] [mailto: >> [EMAIL PROTECTED] *En nombre de *Dario Quintana >> *Enviado el:* Domingo, 07 de Septiembre de 2008 11:46 p.m. >> >> *Para:* [email protected] >> *Asunto:* [NHibernate-Hispano] Re: Pertsistiendo un miembro derivado >> >> Carlos, >> Se me ocurre al vuelo, podrías ensuciar la property con un dummy para >> poder disparar el Update, y luega sobreescribirla en la intercepción. >> >> On Sun, Sep 7, 2008 at 11:13 PM, Carlos Peix <[EMAIL PROTECTED]>wrote: >> >>> Hola Dario, >>> >>> Estoy con NH 1.2.1... >>> >>> Estuve probando la recomendacion de Gustavo pero creo que en el caso de >>> ILifeCycle, IInterceptor o IUserType, en todos ellos me pasa los mismos, NH, >>> por algun motivo, cree que no he modificado el objeto si lo unico que he >>> tocado es este campo con una persistencia especial. >>> >>> Estoy seguro de que estoy cometiendo otro error. >>> >>> Carlos Peix >>> >>> ------------------------------ >>> *De:* [email protected] [mailto: >>> [EMAIL PROTECTED] *En nombre de *Dario Quintana >>> *Enviado el:* Domingo, 07 de Septiembre de 2008 09:01 p.m. >>> *Para:* [email protected] >>> *Asunto:* [NHibernate-Hispano] Re: Pertsistiendo un miembro derivado >>> >>> Hola Carlos, >>> Leyendo al vuelo sin analizar mucho, que problemas hay con EventListeners >>> ? Por que veo que no los probaste según lo que nombrás. >>> >>> Un Abrazo >>> >>> On Sun, Sep 7, 2008 at 4:21 PM, Carlos Peix <[EMAIL PROTECTED]>wrote: >>> >>>> >>>> Hola gente, estoy enredado con el siguiente problema. >>>> >>>> Tengo un objeto persistente mas o menos asi: >>>> >>>> public class Ejemplo { >>>> >>>> // Este miembro no es persistente >>>> private object dynamicData; >>>> public object DynamicData { >>>> get { >>>> return dynamicData; >>>> } >>>> } >>>> >>>> // Este miembro es el que se persiste como un XML >>>> private string serializadData; >>>> } >>>> >>>> Este es el mapping: >>>> >>>> <class name="Extensible" table="Extensibles"> >>>> >>>> <id name="Id"> >>>> <generator class="guid.comb"/> >>>> </id> >>>> >>>> <property name="SerializedData" length="5000" >>>> access="field.camelcase"/> >>>> >>>> </class> >>>> >>>> Lo que me gustaria hacer es, cuando el objeto se carga desde la base de >>>> datos, deserializar de esta manera: >>>> >>>> // SerializationHelper es una clase mia >>>> dynamicData = SerializationHelper.Serialize(serializadData); >>>> >>>> Y antes de persistir hacer esto: >>>> >>>> // SerializationHelper es una clase mia >>>> serializadData = SerializationHelper.Deserialize(dynamicData); >>>> >>>> El problema es que no logro hacerlo ni con ILifeCycle ni con >>>> Iinterceptor, >>>> parece que Nhibernate no dispara el update porque no detecta cambio en >>>> ese >>>> miembro, lo cual es logico porque no cambia hasta que no lo serializo de >>>> nuevo. >>>> >>>> Necesito tener esta representacion dual del objeto porque, por un lado, >>>> tengo que persistirlo en XML y por el otro, tengo que disponer de el >>>> como >>>> instancia de objeto. >>>> >>>> Alguna pista? Alguna otra manera de hacer esto? >>>> >>>> Carlos Peix >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Dario Quintana >>> http://darioquintana.com.ar >>> >>> >> >> >> -- >> Dario Quintana >> http://darioquintana.com.ar >> >> > > > --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
