Bug in NHibernate 2.1 die Dritte

Da dachte ich, ich hätte den Fehler in der Example-Klasse, wie hier schon beschrieben, behoben. Allerdings fand ich dann in der nhusers-Group diesen Beitrag.

Joe Smith beschreibt zuerst den Fehler, den ich schon mit einem Patch behoben hatte. Doch dann stellte sich heraus, dass es ein weiteres Problem für Oracle Datenbanken im Zusammenhang mit der LikeExpression zu geben scheint.

Oracle macht einen unterschied, ob man "like 'UPPER%'" oder "like 'lower%' schreibt. Bei mir tritt das Problem nicht auf, da ich momentan entweder mit MySQL oder MS-SQL arbeite und dort like case insensitive ist.

Nach ca. 30 Minuten suchen im NHibernate Quelltext habe ich das Problem gefunden. Wenn die LikeExpression auf ignoreCase geschaltet wird, wird nur für die geprüfte Spalte lower() aufgerufen jedoch nicht für den übergebenen Parameter. Ich habe für Joe auf die schnelle einen Patch fertig gemacht indem lower() auch für den Parameter aufgerufen wird. Diesen habe ich auch an NHibernate-JIRA geschickt, mit der Anmerkung, dass das gleiche Problem auch in der InsensitiveLikeExpression besteht (warum gibt es eigentlich zwei unabhängige Klassen und nicht eine, die auf die Andere aufbaut?).

Eigentlich dachte ich, damit sei die Sache erst mal erledigt aber Fabio Maulo ist wohl nicht der Ansicht, dass dieses Verhalten ein Bug sei. Schließlich sei der Entwickler seiner Meinung nach selbst für den Parameter verantwortlich und nicht NHibernate.

Das macht für mich allerdings überhaupt keinen Sinn.

1. Wenn ich NHibernate mitteile, dass es case insensitive arbeiten soll, dann ist mir doch egal wie der Parameter aussieht, es soll einfach case insensitive arbeiten.
   
2. Das Verhalten vor NH2.1 scheint genau so gewesen zu sein, wie von Joe (und mir) eigentlich erwartet. Von daher soll es sich doch auch mit NH2.1 weiterhin so verhalten.
   
3. Wenn ich mich selbst um den Parameter kümmern muss, müsste ich auch wissen darüber haben, wie NHibernate arbeitet. Ich weiß erstmal nicht, dass lower() angewendet wird. Könnte ja auch sein das jemand gerne upper() verwendet. Ich weiß es nicht. Dies ist ein reines Implementierungsdetail und als Benutzer sollte es mir vollkommen egal sein können.

Bis jetzt kam leider keine weitere Antwort zu dem Thema. Allerdings ist mir in diesem Zusammenhang ein weiterer möglicher Bug aufgefallen. Aber dazu später mehr.