El día 19 de junio de 2008 23:29, Diego Jancic <[EMAIL PROTECTED]> escribió:
> > Ahora, antes de que me putees, estoy usando criteria para hacerlo, pero a > veces es complicado y no puedo (o termino con un choclo) Ya se.. sos el que mas usa el DynQuery y la verdad es que me encanta que te sea util. Yo tambien me estuve peliando con Criteria y aunque se haya mejorado y el QueryTranslator de HQL tiene limitaciones (vos sabes cuales) Criteria aún no llega a HQL. La pregunta es: > *Normalmente* el HQL final no va a cambiar, pero puede ser que tenga varios > queries de este estilo. Me conviene (en complejidad y beneficio) mejorar el > "Most Recently Used" cache de queries ?? > Lo ideal seria primero ver el MRU cache para ver que queries hay en el > momento y ver si hay mucha "rotación" (y por lo tanto recompilacion). > > Mi idea era agrandar el tamaño del cache (que ahora es 128), what do you > think? Me estas diciendo que vas a tener fuentes de NH compilados para vos? Si te lee Carlos, que nisiquiera se banca una Alpha2, se desmaya. Yo me banque, y me banco, aplicaciones que andan con el trunk de NH pero soy conciente que es porque, digamos..., soy conciente de lo que pasa en NH. Hubo veces que un breaking change me resultaba molesto en un aplicación pero eso ya es cosa para hablar con un psicologo... Podes agrandar el QueryPlanCache pero me parece que en este caso es tu aplicación la que pierde tiempo en construir queries. Creo que deberías poner un log de forma de capturar las combinaciones mas usadas y esas pasarlas a HQL mapeados; de esa manera nadie tiene que parsear nada. A ver.... analisis on the fly (falta un corderito y un malbec pero se puede hacer) Supongamos que tengas una clase que se llama "Pepe". Tenes otra clase que se llama "PepeCriteria" que representa todas la propiedades que te sirven para hacer un query sobre "Pepe". "PepeCriteria" implementa IEqualityComparer<PepeCriteria>. En tu app podes tener una instancia de SoftLimitMRUCache, con el limite que te guste, cuyo par es: int= HashCode de PepeCriteria, string= HQL resultante del DynQuery. De esta forma tendrás un form que llena un "PepeCriteria", ante de empezar a construir el DynQuery lo vas a buscar tu SoftLimitMRUCache si lo encontras lo usas y si no construis el DynQuery y le haces el Put en el cache. De esta forma la probabilidad que desde un "PepeCriteria" se pase directamente a asignar los parametros de una SQL ya preparada empieza a ser mas alta. Que diferencia te da esto en la performance de tu app me queda un minsterio pero se trata de probar. -- Fabio Maulo P.D. A proposito de performance me parece que con la r3568 le puse el turbo a NH cuando trabaja con enums persistentes (solo una curiosidad que queda para comprobar pero esa fue la impresión que tuve). --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
