NHibernate cache

A minap a következő érdekes helyzet állt elő:
NHibernate-el futtattunk lekérdezéseket, és furcsa módon a query ami az adatbázis felé ment, nem azokat az értékeket hozta vissza, mint amikor ugyanazt a query-t PlSql Developerrel lefuttattuk, ugyanazon az adatbázison.
A rekordok száma stimmelt, de a sorok tartalma nem. Első hallásra olyan misztikusnak hangzik, és nem nagyon tudja az ember elképzelni hogy hova nyúljon, mit nézzen meg.
Sejtettük hogy valami cache gebasz lesz, de hát hogy, mit cache-el, és hogy stimmel a rekordok száma?

A probléma a következő volt:
Az NHibernate nem tud létezni primary key és Id mező nélkül. Mivel a select egy 4 selectből álló union-ból való lekérdezés volt, nem lehetett kiválasztani a lekérdezett táblákból egyet, aminek a primary key-ét Id-ként visszaadjuk, mert hol az egyik tábla PK-ja null, hol a másiké. Ezért a selectbe egy "Id" aliassal bekerült a ROWNUM, vagyis az, hogy hányadik sor. Ez teljesen jó megoldásnak tűnt.

Azonban az NHibernate megjegyezte hogy ugyanaz a query (ugyan más paraméterekkel) lefutott már, megnézte az Id mezők tartalmát, és mivel egy előző query már hozott vissza sorokat amiknek az Id mezője mondjuk 1-9 ig volt, így az előző lekérdezés eredményeit adta vissza. Viszont az új query sorainak számát meg tudta, így a sorok száma megfelelő volt.
Tehát erre egy jó megoldás az, ha ilyen esetben az Id mezőbe nem ROWNUM-ot hanem GUID-ot rakunk, vagy mindig töröljük a cache-t mielőtt az ilyen problémás query-ket futtatjuk.

Szép kis esti szopás volt.