This post is somewhat a continuation of last month's post which covered the usage of Lucene in the same Use Case - at an earlier stage: https://www.elbisch.ch/2019/05/31/full-text-search-for-database-entities-with-lucene-net/
Lucene is a search engine, but it can do more than just that. Calculating scores representing the relevancy of a search result in comparison to another and thus ordering the results is just as much a core feature of the framework as is indexing and searching. And just like any other aspect of Lucene, the defaults for sorting and scoring may work well for many use cases, it's very well possible to customize almost every aspect of it if what Lucene delivers by default is not what is wanted. However there are some scenarios which seem to be considerable harder to achieve, one of which I want to showcase in this post.
In this post I describe a solution I developed for a Use Case where the main factor for sorting are metadata. That metadata are numerical values which each correspond to an indexed field, and the higher that value, the more the field is worth. A field's "worth" should then be considered in the sort scoring.
The library Apache Lucene, originally written in Java, has found itself being used very often when it comes to the need of being able to search, and has by now been ported to many other languages and has been used in many other products such as ElasticSearch. The C# port Lucene.NET is very closely modelled after the Java original. It offers a vast amount of options to tailor the search behaviour to ones very specific needs. But with that flexibility comes the price of increased complexity. A lot of terms and concepts need to be understood if the search engine framework wants to be used for something else than the commonly described standard use-case. One such more specialized Use-Case for Lucene is described in this blog post. And given Lucene.NET is by choice as resemblant of the original as possible, the findings of this post may very well be eligible for other languages and environments as well.
The code and concepts for this post describe the usage for an ASP.NET MVC App using Lucene.NET version 3.0.3. As the API documentation seems to be unavailable currently, refer to the corresponding Java API documentation for primary research: https://lucene.apache.org/core/3_0_3/api/all/index.html
In diesem Blogpost möchte ich auf ein Problem eingehen, mit welchem ich in meinem aktuellen Projekt konfrontiert war. Das grundlegende Problem ist dabei nicht sehr exotisch und kann sehr wahrscheinlich auch in anderen Projekten auftreten, und dort wohl auch ähnlich gelöst werden.
There are many games these days which require the players to thoroughly explore vast virtual worlds which may take more time than some are willing or able to invest. Or there are hidden features on a map to which players may want to return at some point, without having to skim through the map over and over again. Given that it is very common to find dedicated fans of the game which take the time to not only do the exploration but also note down their findings in annotated maps. This blog post is about bringing such an ingame map to a user-friendly web page.
Eine der grössten Herausforderungen beim Design einer neuen Applikation ist wohl das Design des Domain Models, beziehungsweise der Datenbank, welche der Applikation als Fundament dient. Die Entitäten, welche hier definiert werden, kommen oft an vielen Stellen in der Applikation wieder zur Verwendung. Entsprechend gravierend sind zu spät festgestellte Fehler im Datenmodell, und entsprechend schwierig ist es, diese nachträglich noch zu korrigieren.
Deshalb möchte ich an dieser Stelle ein Element für die Modellierung des Domain Models vorstellen, welches sich so im klassischen SQL zwar nicht findet, aber dank Abstraktion dennoch möglich ist: Vererbung.