mmm me parece que se por donde viene la mano (fuy a leer el primer mail y el primer consejo de Carlos). El motivo de fondo me parece que sea relacionado con el ParameterType que por default NH "no asigna" (ojo a las comillas). Creo que con prepare_sql se resuelva pero no estoy seguro (no creo que tengamos tests con eso).
El 12 de enero de 2010 16:18, Carlos Peix <[email protected]> escribió: > Hola Edgar, > > Por mi ya esta bien, sugiero que no te metas en mas complicaciones y dejes > el VARCHAR(60) o algo mas abreviado, como sugiere Jose (el cordobes > apurado), la solucion optima seria colocar un CHAR(3) y asegurarte de que > todos los discriminadores ocupen 3 caracteres (total ese valor no lo ves mas > que en el mapeo y podrias cambiarlo en el futuro sin impacto en tu > aplicacion). > > El usertype que sugiere Fabio lo dejaria para mas adelante como un > technical debt (deuda tecnica: algo que por ahora funciona pero que seria > bueno mejorar en el futuro). > > Muchas gracias > > ---------------------------------- > Carlos Peix > > 2010/1/12 Edgar Ramos <[email protected]> > > el discriminador puse de tipo <discriminator column="Tipo" >> type="AnsiString(60)"/>, pero el error volvio a aparecer, si me >> ayudas Carlos que mas tengo que hacer para probar >> >> voy a chequear el link de Fabio >> >> El día 12 de enero de 2010 13:59, Edgar Ramos <[email protected]> >> escribió: >> > este momento hago las pruebas, desde luego no faltaba mas >> > >> > cambio el campo a char(60), y en el archivo de mapeo hago >> > type="AnsiStringFixedLength(60)" verdad !!! >> > >> > El día 12 de enero de 2010 13:01, Carlos Peix <[email protected]> >> escribió: >> >> Bueno, pero me basta con que NH no se confunda porque el graba un >> "0123456" >> >> y luego busca lo mismo cuando haces el query de una subclase pero, >> desde la >> >> base, le vuelve un "0123456 ". >> >> Si NH, internamente, hace algun "".Equals(), sonamos. Me imagino que no >> >> porque, caso contrario, nos habriamos enterado. >> >> Edgar, en retribucion a la comunidad, podrias cambiar el tipo de dato >> en la >> >> columna de la BD de nuevo a CHAR(60) y contarnos si todo sigue >> funcionando? >> >> Gracias >> >> ---------------------------------- >> >> Carlos Peix >> >> >> >> 2010/1/12 Fabio Maulo <[email protected]> >> >>> >> >>> Si pero ojo que "0123456" != "0123456 " >> >>> quien modifica el valor es el DB o tu clase, NH no lo toca. >> >>> >> >>> El 12 de enero de 2010 14:50, Carlos Peix <[email protected]> >> >>> escribió: >> >>>> >> >>>> Ahhh, perfecto. >> >>>> Graciassss >> >>>> ---------------------------------- >> >>>> Carlos Peix >> >>>> >> >>>> 2010/1/12 Fabio Maulo <[email protected]> >> >>>>> >> >>>>> usando: >> >>>>> type="AnsiStringFixedLength(10)" >> >>>>> le estas diciendo a NH que el type en el DB es CHAR(10). >> >>>>> Además le estas diciendo a NH como va a funcionar ese campo y que si >> >>>>> encuentra "0123456" en la propiedad, el valor del campo será >> "0123456 " >> >>>>> La respuesta a la pregunta es: Yes, you can >> >>>>> >> >>>>> El 12 de enero de 2010 14:20, Carlos Peix <[email protected]> >> >>>>> escribió: >> >>>>>> >> >>>>>> Uh? Bueno, muy bien, pero aun me queda la duda. Seria bueno usar >> CHAR >> >>>>>> si se puede. Se puede? >> >>>>>> Dale, escribi un poquitin mas, te espero mientras pongo el agua >> para el >> >>>>>> mate. >> >>>>>> Grazie >> >>>>>> ---------------------------------- >> >>>>>> Carlos Peix >> >>>>>> >> >>>>>> 2010/1/12 Fabio Maulo <[email protected]> >> >>>>>>> >> >>>>>>> type="AnsiString" >> >>>>>>> >> >>>>>>> El 12 de enero de 2010 13:48, Carlos Peix <[email protected]> >> >>>>>>> escribió: >> >>>>>>>> >> >>>>>>>> Hola Tano, >> >>>>>>>> Esto quiere decir que no es recomendable usar campos CHAR para el >> >>>>>>>> discriminator? (en estos campos SQLServer completa con espacios a >> la derecha >> >>>>>>>> pero creo que ya sabrias esto) >> >>>>>>>> Es razonable que NH se confunda ya que graba un "Transferencia" y >> >>>>>>>> obtiene un "Transferencia " pero tambien seria bueno que >> NH no se >> >>>>>>>> fuera de mambo con esto puesto que es bastante comun. >> >>>>>>>> Por ultimo, segun creo, los indices sobre CHAR son mas eficientes >> (en >> >>>>>>>> velocidad de lookup, no en almacenamiento) que sobre VARCHAR y es >> altamente >> >>>>>>>> probable que esta columna sea indexada puesto que participa del >> query, en >> >>>>>>>> general. >> >>>>>>>> Como siempre, le pertenezco... >> >>>>>>>> Gracias >> >>>>>>>> ---------------------------------- >> >>>>>>>> Carlos Peix >> >>>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Para escribir al Grupo, hágalo a esta dirección: >> >>>>>> [email protected] >> >>>>>> Para más, visite: >> http://groups.google.com/group/NHibernate-Hispano >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Fabio Maulo >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> 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 >> >>> >> >>> >> >>> >> >>> -- >> >>> Fabio Maulo >> >>> >> >>> >> >>> -- >> >>> 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 > -- Fabio Maulo
-- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
