NHibernate

Evitate se possibile NHibernate not-found=”ignore”

Gian Maria Ricci — Wed, 19 Jun 2013 22:07:00 GMT

Se avete un legacy database dove alcuni processi fanno manipolazioni del database al di fuori del vostro controllo potreste trovarvi in una situazione in cui l’entità A referenzia l’entità B con una many-to-one, e quindi la tabella dove viene salvata l’entità A ha una foreign-key verso la tabella B.

Supponiamo inoltre che la tabella A sia stata introdotta in un momento successivo, e ci sono processi che cancellano record dalla tabella usata per salvare l’entità B, lasciando quindi i record di A orfani. In questa situazione NHibernate genererà un errore a runtime quando si tenta di accedere alla relazione di una entità orfana, perchè il lazy load non riesce a caricare la corrispondente entità B, pur avendo un id nella colonna della foreign-key.

Una possibile soluzione è utilizzare l’opzione not-found=”ignore”, la quale permette di dire a nhibernate di ignorare questa situazione, se nella tabella dell’entità A ci sta un riferimento ad una entità B che non è più presente, si può ignorare questo errore, e lasciare la corrispondente proprietà di navigazione a null.

Questa però è una soluzione poco efficiente per molte ragioni. La prima è che NHibernate effettuerà sempre la query per tentare di recuperare l’entità B correlata, quindi ogni volta che caricate una entità A viene sempre fatta una ulteriore select per capire se la corrispondente Entità B esiste, quindi non viene più applicato il lazy load. Quando caricate liste di entità il problema potrebbe diventare anche peggiore.

La soluzione in questo caso è una sola, fare in modo che il database non abbia foreign-key orfane, perchè avere una base dati di questo tipo è veramente molto pericoloso, quindi se avete dei processi fuori dal vostro controllo, non dimenticate la ON DELETE SET NULL, che permette di mantenere l’integrità referenziale in maniera automatica, e quindi evitando di dover ricorrere a delle opzioni “pericolose” di NHibernate.

Alk.

NHibernate, criteria query e relazioni

Gian Maria Ricci — Tue, 04 Dec 2007 21:22:21 GMT

Supponiamo di avere le classi Customers e Orders del database northwind, abbiamo implementato la relazione many-to-one bidirezionale nel nostro domain model, così da avere una collection orders nella classe Customer, ed una proprietà Customer nell'oggetto order. Ora se si vuole prendere tutti gli ordini di "ALFKI" in un determinato range di tempo si può scrivere questa criteria query

ICriteria criteria = session.CreateCriteria(typeof (Order));
criteria.Add(Expression.Between("OrderDate", new DateTime(1997, 10, 1), new DateTime(1998, 1, 1)));
Customer cust = session.Load<Customer>("ALFKI");
criteria.Add(Expression.Eq("Customer", cust));
IList<Order> result = criteria.List<Order>();

Notare come il riferimento all'oggetto Customer sia recuperato tramite il Session.Load() cosi da creare un proxy e non andare a disturbare il database. Ma cosa succede se la relazione non è implementata in maniera bidirezionale, ma unidirezionale? Ad esempio se l'oggetto Order non ha nessuna proprietà che punta all'oggetto Customer? In questo caso è possibile fare una criteria query un po' "sporchina" dato che andiamo a referenziare direttamente i campi del nostro database. Ecco come fare:

ICriteria criteria = session.CreateCriteria(typeof(Order2));
criteria.Add(Expression.Between("OrderDate", new DateTime(1997, 10, 1), new DateTime(1998, 1, 1)));
criteria.Add(Expression.Sql("{alias}.CustomerId = ?", "ALFKI", NHibernateUtil.String));
IList<Order2> result = criteria.List<Order2>();

Come si può vedere NHibernate fornisce un comodissimo criterio Sql che permette di inserire condizioni su campi non mappati nel domain model, chiaramente questo è poco object oriented, ma è un altro degli strumenti da tenere nella cassetta degli attrezzi e da usare quando serve.

A questo punto però i puristi storcerebbero il naso, cosa succede se cambio il nome dei campi del db? Con Nhibernate non dovrei mai fare query che contengono il nome dei campi sql!!! Si lo so avete ragione ed infatti anche se abbiamo una relazione unidirezionale da Customer a Orders tramite la proprietà Orders di Customer possiamo fare uso di subquery tramite la Criteria API

DetachedCriteria subquery = DetachedCriteria.For(typeof (Customer2))
   .SetProjection(Projections.Property("Id"))
   .CreateAlias("Orders", "Orders")
   .Add(Expression.Eq("Id", "ALFKI"))
   .Add(Property.ForName("Orders.Id").EqProperty("order.Id"));

ICriteria criteria = session.CreateCriteria(typeof(Order2), "order");
criteria.Add(Expression.Between("OrderDate", new DateTime(1997, 10, 1), new DateTime(1998, 1, 1)));
criteria.Add(Subqueries.Exists(subquery));
IList<Order2> result = criteria.List<Order2>();
Assert.That(result.Count, Is.EqualTo(2));

Che genera la seguente query in SQL

exec sp_executesql N'SELECT this_.OrderId as OrderId1_0_, this_.OrderDate as OrderDate1_0_ FROM dbo.ORders this_ WHERE this_.OrderDate between @p0 and @p1 and exists (SELECT this_0_.CustomerId as y0_ FROM dbo.Customers this_0_ inner join dbo.ORders orders1_ on this_0_.CustomerId=orders1_.CustomerId WHERE this_0_.CustomerId = @p2 and orders1_.OrderId = this_.OrderId)', N'@p0 datetime,@p1 datetime,@p2 nvarchar(5)', @p0 = 'Oct 1 1997 12:00:00:000AM', @p1 = 'Jan 1 1998 12:00:00:000AM', @p2 = N'ALFKI'

Alk.

Technorati tags:NHibernate

Provider di connessione per nhibernate - Precisazioni

Gian Maria Ricci — Fri, 03 Aug 2007 23:56:00 GMT

Nel precedente post ho spiegato come realizzare un provider custom per le connessioni in nhibernate al fine di potere iniettare una connessione in una sessione. Per completezza è il caso di citare che il metodo SessionFactory.OpenSession() ha una versione in overload che accetta un oggetto IDbConnection come parametro. Il risultato è praticamente analogo e sicuramente si scrive meno codice rispetto all'esempio precedente. Il contro di questa tecnica è che spesso si debbono eseguire dei test su classi che internamente creano una sessione (o prendono quella della conversazione corrente). Queste classi chiaramente invocano il metodo SessionFactory.OpenSession() senza preoccuparsi della gestione della connessione e grazie al ConnectionProvider si può intervenire trasparentemente iniettando la propria connessione senza che il codice di produzione si accorga della differenza.

Alk.

Provider di connessioni per nhibernate

Gian Maria Ricci — Fri, 03 Aug 2007 22:56:00 GMT

Debbo dire che più conosco nhibernate più lo apprezzo veramente tanto. Stasera mi sono chiesto, posso iniettare una mia connessione in una sessione? Lo scopo di una simile operazione è vario, potrei ad esempio iniettare una connessione durante un test per potere poi fare query dirette al database e verificare che i dati siano scritti bene, oppure potrei volere eseguire codice SQL diretto assieme a nhibernate in una unica transazione etc etc. LA soluzione a questo problema è veramente banale :D.

Nhibernate definisce un interfaccia chiamata IConnectionProvider tramite la quale la sessionFactory recupera la connessione da dare in pasto alla sessione, solitamente viene utilizzato un provider di default definito da queste due righe di configurazione.

NAturalmente se si volesse creare un proprio provider è sufficiente ereditare da una classe astratta chiamata ConnectionProvider, di cui è possibile implementare la sola funzione GetConnection().

public class MyConnectionProvider : ConnectionProvider  {

   public override System.Data.IDbConnection GetConnection() {
      IDbConnection conn = new SqlConnection("Server=localhost\\sql2000;initial catalog=NorthWind;User Id=sa;password=ottaedro_2006@");
      conn.Open();
      return conn;
   }
}

Come si può vedere nell'esempio in questione la connessione viene costruita con una stringa hardcoded, ma le possibilità sono indubbiamente aperte alla nostra fantasia. Chiaramente per sfruttare questo nuovo provider di connessioni è necessario specificare la classe desiderata nel file di configurazione e la connessione restituita deve essere stata precedentemente aperta.

Non dimenticate di mettere sempre la configurazione connection_string perchè se non presente l'oggetto ConnectionProvider di base genererà un eccezione.

Alk.