Um erst einmal eins vorweg zu sagen, ich mag NHibernate wirklich sehr. Ich will dieses Tool nicht schlecht machen oder so, auch wenn ich in letzter Zeit viel über Bugs oder komische Codestellen berichte. Es ist ein sehr gutes Tool und wenn mir die Qualität nicht passt habe ich selbst die Möglichkeit etwas dran zu ändern.
Da ich in letzter Zeit vermehrt in den Sourcecode von NHibernate reingeschaut habe, sind doch ein paar Stellen aufgefallen die ich einfach grottig fand. Eine von diesen werde ich kurz erläutern.
In der Klasse Configuration gibt es die Methode BuildSessionFactory(). Diese sieht momentan so aus:
public ISessionFactory BuildSessionFactory()
{
ConfigureProxyFactoryFactory();
SecondPassCompile();
Validate();
Environment.VerifyProperties(properties);
Settings settings = BuildSettings();
// Ok, don't need schemas anymore, so free them
Schemas = null;
return new SessionFactoryImpl(this, mapping, settings, GetInitializedEventListeners());
}
Die rot markierte Zeile ist das Interessante an der Sache. Wenn ich so in den Qullcode schaue, würde ich ja denken hier werden Properties überprüft. Wenn wir uns nun mal die Methode anschauen stellen wir fest ...
/// <summary>
/// Issue warnings to user when any obsolete property names are used.
/// </summary>
/// <param name="props"></param>
/// <returns></returns>
public static void VerifyProperties(IDictionary<string, string> props) {}
sie macht garnichts!
Sehr cool finde ich den Kommentar.
Samstag, 5. September 2009
Donnerstag, 3. September 2009
.NET Open Space 2009
Bald ist es wieder soweit. Zum zweiten mal findet in Leipzig am 17. und 18. Oktober die .NET Open Space statt. Dort wird es wieder spannende Diskussionen rund um die Softwareentwicklung, hauptsächlich im Bereich .NET geben. Mittlerweile ist die maximale Teilnehmeranzahl fast erreicht.
Ich freue mich auf jeden Fall darauf. Wir werden uns dort sehen.
Ich freue mich auf jeden Fall darauf. Wir werden uns dort sehen.
Mittwoch, 2. September 2009
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.
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.
- 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.
- 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.
- 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.
Abonnieren
Kommentare (Atom)