Damwild aus dem ODC

Vom JdV (Jäger des Vertrauens) gab es eine schöne Damwildkeule, die ich auf den Grill legen sollte. Sozusagen als Test für einen Abend mit den Jungs, der in Zukunft dann geplant wird.
Wild-technisch bin ich absoluter Neuling, wenn also jemand "Zeter und Mordio" aufgrund der Behandlung schreien sollte, dann nur her mit der Kritik.

Angefangen habe ich damit, dass ich das Gemüsebett für die Keule bereitet habe.

Im zweiten Schritt wurde die kritische... ähhh... Grundmasse für die Semmelknödel erstellt.

Danach wurde die Keule ein wenig pariert und die Abschnitte für ein kleines Gulasch vakuumiert.

Darauf konnte die Gewürzmischung aus gestoßenem Salz, Pfeffer, Rosmarin, Majoran und ein wenig Salbei bereitet werden.

Diese wurde dann in das Fleisch einmassiert und die Schulter auf ihrem Bett drapiert.

Um ein Austrocknen zu verhindern wurde die Schulter mit Speck umwickelt. Mit den Worten des Texaners "Everything wrapped in Bacon tastes better".

Der Grill war in der Zeit schon auf knapp 125°C vorgeheizt und wurde mit dem Braten inkl. Gemüsebett bestückt. Während der Garzeit wurde noch eine kleine Soße aus dem Knochen und ein wenig Rotwein bereitet.

Bei einer KT von 55°C wurde der Braten aus dem Grill genommen und wurde für ein paar Minuten zum ruhen gebettet.

Danach folgte der Anschnitt und das folgende Bild ergab sich.

Näher ran?

Insgesamt mit den Semmelknödeln und ein wenig Sahnekohlrabi super lecker! Sehr zart und wirklich toll vom Geschmack! Das gibt es wieder, wenn auch diesmal ohne Speck, der war eigentlich nicht von Nöten!

Bon Appetit!

In der Weihnachtsbäckerei...

Das Singen erspare ich den meisten einfach mal und poste nur die Bilder der ersten Plätzchen-Back-Aktion in diesem Jahr.
Ich selber mag Plätzchenbacken ja nicht so, dieses sklavische An-Das-Rezept-Halten liegt mir da nicht so...


Teig anrühren und kneten. Natürlich per Hand ;)

Ausstechen. Nicht meine Arbeit. Nach zehn Mal ausstechen ist die Menge des Teigs immer noch nicht kleiner geworden :-D

 Backen.

 Zuckerglasur mit Schnapps druff!

Bon Appetit ;-)

Flammkuchen vom ODC

Hunger? Dann habe ich hier das Richtige :)

Flammkuchen vom Outdoorchef. Genau das Richtige für ein deftiges Frühstück oder einen kleinen Snack zwischendurch.

Der Teig wird aus 405 Mehl Typ 00 gemacht, damit er schön fein ist. Dafür benötigt man Hefe, Salz und ein wenig Wasser bis der Teig die richtige Konsistenz hat.

Im zweiten Schritt werden Zwiebeln und Speck in feine Ringe bzw. Stücke geschnitten. Der Teig sollte in der Zwischenzeit ein wenig ruhen und gehen.

 Danach den Teig auf einer bemehlten Fläche ausrollen.

Auf Blech verfrachten.

 Mit Creme Fraîche bestreichen, Salz und Pfeffer applizieren.

 Und mit den geschnittenen Zwiebeln und dem Speck belegen.

Tasty :)

Die Kugel auf knapp 300°C vorheizen und das Blech hinein in den Grill.

Mit dem gewünschten Bräunungsgrad wieder raus aus der Hitze und direkt und heiß essen.

Bon appetit ;)

Quick & Dirty - JPA Native Queries und die Ergebnismenge 2

Die bereits vorgestellte Lösung für das Mappen nativer Ergebnismengen ist durchaus akzeptabel, wenn keine null-Werte innerhalb des Resultsets vorkommen.
Da das Vorkommen von null-Werten allerdings leider eher die Regel als eine wenig zu beachtende Ausnahme ist muss an der Realisierung noch etwas gefeilt werden.

Die Realisierung mit Hilfe des erstellten Arrays aus Klassen anhand der Objekte in der Ergebnismenge ist somit hinfällig und kann nicht mehr als Ausgangspunkt für eine Lösung dienen.

Die aktualisierte Fassung baut auf einer selbst definierten Annotation auf, welche über einem Konstruktor nach Wahl notiert wird. Dabei wird für die Annotation ein sprechender Mappingname vergeben, so dass auch mehrere dieser Annotation innerhalb einer Klasse vergeben werden können.

Der Ablaug des Mappings lässt sich im Groben wie folgt skizzieren:

Basis für das Mappen der Bean ist die entsprechende Annotation innerhalb der zu mappenden Bean. Dafür wird eine selbst definierte Annotation verwendet.

Für das Definieren der Annotation wir der Retention-Type Runtime verwendet, da die Annotationen auch zur Laufzeit noch vorhanden sein sollten. Die Annotation an sich soll nur über den entsprechenden Konstruktoren verwendet werden, so dass keine andere Nutzung gegeben ist. Dies bietet den Vorteil, dass in einem zweiten Schritt nur die Konstruktoren aus der zu mappenden Bean analysiert werden müssen. @Documented zeigt an, dass auch diese Klasse innerhalb des Javadocs erscheinen soll. Dies wäre ohne die Annotation nicht der Fall.

Die Klasse ResultSetMapper muss nun dahingehend verändert werden, dass die Menge an Konstructoren durchsucht wird und der gewünschte Konstruktor herausgestellt wird.

Im ersten Schritt werden die in der Klasse deklarierten Konstruktoren mittels Reflection ermittelt. Der zweite Schritt dient nun dem Ermitteln des gewünschten Konstruktors anhand der Annotation und dem spezifischen Namen des Mappings.

 Im zweiten Teil der Methode muss nun die neue Instanz der Bean erzeugt werden. Dies lässt sich über den gefunden Konstruktor realisieren. Sollte kein Konstruktor gefunden worden sein, so wird eine entsprechende Exception (siehe 1) geworfen. Sollte bei dem Erstellen der Instanz eine falsche Parameteranzahl oder -reihenfolge angegeben worden sein, so wird eine ParameterMismatchException geworfen.

Damit ist nun auch ein Mappen von ResultSets möglich, die null-Werte enthalten.

Quick & Dirty - JPA Native Queries und die Ergebnismenge

Ein Problem beim Absetzen von nativen Queries ist die unkomplizierte komplizierte Verarbeitung der Ergebnisse. Anstatt durch ein Array von Objekten zu iterieren wäre es ja durchaus wünschenswert, wenn man die Ergebnisse der Query direkt in eine zugehörige Bean transportieren kann.
Leider ist mit der Annotation @SqlResultSetMapping nur ein Mappen von Entitäten möglich, aber nicht von einfachen Beans, die für einen Datenaustausch oder eine Visualisierung innerhalb der GUI benötigt werden.

Um diesem Problem aus dem Weg zu gehen, habe ich einen kleinen Mapper erstellt, der es ermöglicht aus einer Liste, welche die Ergebnisse der Query in Arrays von Objekten enthält, eine Liste der gewünschten Beans erzeugt.

1. An dieser Stelle werden die entsprechenden Klassen der Objekte ausgelesen und in ein Array gesteckt. Dies ist notwendig, damit man im zweiten Schritt mit Hilfe der Java Reflection API nach einem zugehörigen Konstruktor schauen kann.
2. Suche nach dem Konstruktor mit der zugehörigen Signatur, die durch die Liste der Spalten innerhalb der Ergebnismenge definiert ist.
3. Erstellen der entsprechenden Beans und hinzufügen zur Liste der Ergebnisse.

Narrensicher ist die Art der Konvertierung nicht. Die Konvertierung basiert im wesentlichen auf der Annahme, dass die Arrays innerhalb des Result Set grundsätzlich gleich sind und keine null-Werte enthalten sind. Sollte also jemand Verbesserungen bzw. Anregungen haben, dann immer her damit.

Da dies nur funktioniert, wenn die Liste der Ergebnisse mehrere Spalten enthält, habe ich gleichtzeitig noch eine Methode erstellt, die den unwahrscheinlichen Fall abdeckt, dass eine einzelne Spalte in eine Bean gesteckt werden soll. Daher der Vollständigkeit halber auch diese Methode als Screenshot.