Lo de poder cambiar a HQL esta claro Diego, pero a lo que me refiero es que no va a funcionar exactamente igual si antes tenias que poner el truco del synchronize y despues no. o sea que no es simplemente cambiar SQL a HQL. Segun lo que lei esto es valido solo para updates, con selects no hay problema.
Lo del parse del HQL a SQL obviamente es bueno y es la razon por la que uso named-query siempre Respecto a lo del prepare estas seguro? Es un peligro si es asi. Porque voy a querer que me largue prepare de 100 o 200 queries en HQL que las tengo escritas solo para algunas veces que se ejecuta de algunas maquinas? Es una locura me quita lugar del cache para queries que si ejecuto normalmente y no me aporta nada para una query que ejecuto de vez en cuando...voy a consultarle a Fabio cuando vuelva pero espero que esto no sea automatico o se pueda cancelar al menos. Synchronize es importante tenerlo en cuenta, yo no tengo casos en los que me aportaria algo por ahora, ya que no ejecuto updates con sql-queries en elementos que cacheo, pero no lo tenia presente y ahora si. Saludos. Gustavo. 2009/1/17 Diego Jancic <[email protected]> > Hola Gustavo, > > Conviene usar named-query por otros motivos, pero no porque haga la > sincronización solo… las ventajas que se me ocurren son (de las 2 primeras > no estoy 100% seguro, pero casi): > > - Se parsea el query cuando se crea el SessionFactory, esto > significa que expande lo que esta entre corchetes (ej: select {p.*} from > Persona p), y reemplaza los parametros > > - Tambien, cuando se crea el SessionFactory se manda el "prepare" > al RDBMS, de esta forma queda el parse cacheado para cuando se ejecute por > primera vez. Si el query es muy grande y complejo puede tener sentido. > > - Si algun dia queres lo podes cambiar a HQL sin cambiar el > código. ==> supongo que esta es la principal ventaja que mensiona Fabio > > > > > > Con respecto a la transparencia, no lo hace solo porque en algunos casos es > imposible de saberlo, como cuando se usan SP, cursores que permiten > modificar la tabla, etc… De todas formas el sincronize supongo que no es tan > importante para el que recién comienza por 2 razones: > > - No creo que use cache de segundo nivel. Por lo que el > "espejismo" de informacion va a estar solo dentro de la misma session (cache > de 1er nivel). Si usas session-per-request es casi nada de tiempo, y con un > poco de suerte no te das cuenta. > > - Si usas "identity" como generador de ID, estas forzando a que > vaya a la DB en el momento, y no cuando se le cante. Te doy un ejemplo, en > donde puede variar si usas identity o hilo: > > > > (el código de abajo esta sujeto a confirmación de Fabio, o a alguien que lo > pruebe, pero posiblemente sea verdad ;-)) > > > > Persona p = new Persona(); > > session.Save(p); // Si usas hilo, esto no se ejecuta todavia > > > > session.CreateSQLQuery("update Persona set Edad = Edad + > 1").ExecuteUpdate(); > > > > session.Flush(); // Aca se ejecuta el INSERT > > > > > > Saludos! > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gustavo Ringel > *Sent:* Saturday, January 17, 2009 05:00 > > *To:* [email protected] > *Subject:* [NHibernate-Hispano] Re: Ayuda con un query > > > > Hi Diego, > Gracias por la info sobre synchronize table, no se porque estaba seguro de > que era transparente, pero confirmas lo que advirtio Fredy hay temas con el > Cache segun parece tambien, no solo las otras cosas que mencionamos. > > Estas 100% seguro que no se hace solo? porque en definitiva el propio Fabio > ha recomendado usar named query en esos casos para hacerlo transaparente y > no puso el OJO...bueno, si estuviera aca y no de vacaciones podria decir que > asume que el que escribe <sql-query> sabe lo que hace...voy a ver el tema > bien porque no habia prestado atencion la verdad. > > Saludos. > > Gustavo. > > 2009/1/17 Diego Jancic <[email protected]> > > +1 a lo que dice Gustavo. > > Ademas si lo haces como vos decis es muy probable que tengas problemas > porque se te sobre-escribe la information o NH te devuelve el objeto viejo > (porque hay caches). > > Si vas a usar sql-query deberías usar también el sub tag <synchronize > table="…" /> para evitar problemas. De todas formas no hay nada mejor que > hacer un Get y un Update (a excepción de la performance, pero no creo que > esto pueda ser el primer cuello de botella). > > > > Saludos > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gustavo Ringel > *Sent:* Friday, January 16, 2009 17:42 > *To:* [email protected] > *Subject:* [NHibernate-Hispano] Re: Ayuda con un query > > > > NHibernate no debiera tener problemas de comportamiento con CreateSQLQuery, > de hecho si bien no lo he probado NH te permite hacer un <sql-query> > cacheable...o sea que tiene que andar exacto con el mismo comportamiento que > <query> o criteria > > Gustavo. > > On Fri, Jan 16, 2009 at 9:33 PM, Fredy Treboux <[email protected]> > wrote: > > > Claro, yo asumi que id_operacion era la pk de la tabla Operaciones, > solo por eso lo propuse. > > En cuanto al problema que tenía... quien sabe que podría ser, al hacer > una consulta sql de esa forma puede que se quede con datos incorrectos > en el cache de la session?. > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
