c# - isessionfactory - Rompiendo cambios con la actualización de NHibernate 4
nhibernate features (3)
Puedo ver las novedades y las soluciones en NHibernate 4.0
Me gustaría saber si alguien ha tenido problemas con las actualizaciones de hbm mappings de NHibernate 3 a 4.
Me temo que ahora se está enfocando más en el mapeo fluido. Puedo probar los cambios más evidentes, pero quería saber si hubo algún problema sutil que alguien haya encontrado en un entorno de producción que puede no ser tan obvio al principio.
Parece una actualización importante y es de esperar que exista el riesgo de regresiones.
No me preocuparía demasiado sobre el hbm en sí mismo. FluentNHibernate "compila" a XML que pasa por la capa de mapeo. El propio mapeo por código de NHibernate también usa partes del mismo código que los archivos hbm.
De todos modos, el código de mapeo no ha cambiado mucho. Cualquier regresión es más probable que esté en otras partes.
FYI, encontré un nuevo error que se arroja. Usamos Mapping By Code, y solíamos tener una entidad que tenía múltiples asignaciones de BOLSAS con el tipo Fetch
establecido para Join
a NHibernate v 3.3.x. Esto ya no está permitido en la versión 4.0.x.
Recibimos un mensaje de error de Cannot simultaneously fetch multiple bags.
, lo cual tiene sentido con lo que se necesita detrás de escena, pero técnicamente debería considerarse un cambio radical. NHibernate no fue lo suficientemente amable como para decirnos qué mapeo estaba causando el problema.
Estábamos experimentando el mismo problema con un QueryOver
bastante grande: Cannot simultaneously fetch multiple bags
, con las asignaciones Nhibernate 4 y FluentNhibernate.
La solución fue, en nuestros FluentMaps, establecer AsSet()
(de acuerdo con nuestros campos de respaldo) que al final resolvió el problema.
Según lo solicitado en el comentario, aquí hay una pequeña muestra de nuestras asignaciones antes y después de la excepción:
Este es un escaparate muy simplificado de nuestras clases que causó que Cannot simultaneously fetch multiple bags
. La clase de Entity
abstracta pertenece a la arquitectura S # Arp lite . Antes de los cambios se veía algo como esto
public class OrderHeader : Entity
{
public virtual IList<OrderItem> Items { get; set; }
}
public class OrderItem : Entity
{
public virtual decimal Price {get; set;}
public virtual string ItemNumber {get; set;}
public virtual OrderHeader Header {get; set;}
}
public class OrderHeaderMap : ClassMap<OrderHeader>
{
Id( e => e.Id).GeneratedBy.Native();
HasMany(e => e.OrderItems).Inverse();
}
public class OrderItemMap : ClassMap<OrderItem>
{
Id(e => e.Id).GeneratedBy.Native();
References(e => e.Header).Not.Nullable();
}
Como puede ver, OrderHeader tiene un IList
de elementos. Cambiando esto a
public class OrderHeader : Entity
{
public virtual ISet<OrderItem> Items { get; set; } // ISet here
}
public class OrderItem : Entity
{
public virtual decimal Price {get; set;}
public virtual string ItemNumber {get; set;}
public virtual OrderHeader Header {get; set;}
}
public class OrderHeaderMap : ClassMap<OrderHeader>
{
Id( e => e.Id).GeneratedBy.Native();
HasMany(e => e.OrderItems).Inverse();
}
public class OrderItemMap : ClassMap<OrderItem>
{
Id(e => e.Id).GeneratedBy.Native();
References(e => e.Header).Not.Nullable().AsSet(); // Explicit AsSet
}
Entonces, un ISet
y el AsSet()
explícito en el mapeo hicieron desaparecer el problema. Este fragmento de código está muy simplificado y teníamos varias entidades en QueryOver
con HasMany()
IList
: cuando todas se actualizaron al ISet
, funcionó correctamente.