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!
30.12.2010
12.12.2010
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 ;-)
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 ;-)
11.12.2010
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 ;)
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 ;)
10.12.2010
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.
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.
08.12.2010
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.
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.
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.
- 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.
- Suche nach dem Konstruktor mit der zugehörigen Signatur, die durch die Liste der Spalten innerhalb der Ergebnismenge definiert ist.
- Erstellen der entsprechenden Beans und hinzufügen zur Liste der Ergebnisse.
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.
07.12.2010
Quick & Dirty - JPA SQL Result Set Mapping
Das Mappen von nativen SQL Ergebnisse ist immer dann nützlich, wenn komplexe Queries formuliert werden, die nur nativ gelöst werden können oder performanter sind. Die Ergebnisse liegen dann oft nicht direkt als Entity vor, sondern müssen mühsam auseinandergenommen werden.
Daher bietet JPA die Möglichkeit an ein Mapping für die Ergebnismenge zu definieren.
Das Mapping wird mit Hilfe der @SqlResultSetMapping Annotation definiert und direkt über der entsprechenden Entität angegeben. Dabei besteht die Annotation aus einem, innerhalb der PersistenceUnit eindeutigem, Namen und einer bzw. mehreren Mappingklassen, welche später die Ergebnisse der Query beinhalten. Alternativ kann auch eine Klasse direkt beim Erstellen der nativen Query angegeben werden.
Um das Ganze besser zu verstehen und ein wenig mit den Möglichkeiten herumzuspielen werde ich an dieser Stelle ein paar Beispiele exerzieren.
Der Aufbau des Beispielprojektes entspricht im Wesentlichen dem wie in dem vorangegangenen Quick & Dirty bereits beschriebenen Aufbau. Daher werde ich darauf nicht weiter eingehen. Einzig und allein die Testklasse wird geändert, da der JUnit-Test nun andere Aufgaben erfüllen soll.
Einfachstes Beispiel ist das Auslesen einer kompletten Entität aus der Datenbank. Um das Anlegen wiederholbar zu gestalten und nicht redundant in jedem Test durchzuführen, wird eine entsprechende Methode definiert, welches dies für uns übernimmt.
Da die Entität im weiteren Verlauf nur gelesen werden soll, reicht es, wenn diese einmalig vor Ausführung des Tests angelegt wird. Vorher wird die Tabelle komplett geleert, so dass sich keine Altdaten in der Tabelle befinden.
Um später das Result Set Mapping zu nutzen wird die Klasse Employee noch mit der zugehörigen Annotation versehen. An dieser Stelle der einfachste Fall zuerst. Die Daten werden komplett in die entsprechende Entität geschrieben.
Damit kann nun innerhalb des Tests das Ergebnis der nativen SQL Abfrage direkt in die Entität geschrieben werden. Dabei muss nur auf den Namen des vorher definierten @SqlResultSetMapping verwiesen werden.
Das ist der einfachste Fall des Mappings.
Daher bietet JPA die Möglichkeit an ein Mapping für die Ergebnismenge zu definieren.
Das Mapping wird mit Hilfe der @SqlResultSetMapping Annotation definiert und direkt über der entsprechenden Entität angegeben. Dabei besteht die Annotation aus einem, innerhalb der PersistenceUnit eindeutigem, Namen und einer bzw. mehreren Mappingklassen, welche später die Ergebnisse der Query beinhalten. Alternativ kann auch eine Klasse direkt beim Erstellen der nativen Query angegeben werden.
Um das Ganze besser zu verstehen und ein wenig mit den Möglichkeiten herumzuspielen werde ich an dieser Stelle ein paar Beispiele exerzieren.
Der Aufbau des Beispielprojektes entspricht im Wesentlichen dem wie in dem vorangegangenen Quick & Dirty bereits beschriebenen Aufbau. Daher werde ich darauf nicht weiter eingehen. Einzig und allein die Testklasse wird geändert, da der JUnit-Test nun andere Aufgaben erfüllen soll.
Einfachstes Beispiel ist das Auslesen einer kompletten Entität aus der Datenbank. Um das Anlegen wiederholbar zu gestalten und nicht redundant in jedem Test durchzuführen, wird eine entsprechende Methode definiert, welches dies für uns übernimmt.
Um später das Result Set Mapping zu nutzen wird die Klasse Employee noch mit der zugehörigen Annotation versehen. An dieser Stelle der einfachste Fall zuerst. Die Daten werden komplett in die entsprechende Entität geschrieben.
Damit kann nun innerhalb des Tests das Ergebnis der nativen SQL Abfrage direkt in die Entität geschrieben werden. Dabei muss nur auf den Namen des vorher definierten @SqlResultSetMapping verwiesen werden.
Das ist der einfachste Fall des Mappings.
06.12.2010
Quick & Dirty - JPA Constructor Expressions
JPA Constructor Expressions sind immer dann nützlich, wenn fein-granulare Objekte zum Austausch von Daten erzeugt werden sollen. Anstatt die Daten per Hand zusammenzustellen oder einen Assembler wie den GEDA DTO Assembler zu nutzen, können die Daten direkt in entsprechenden Objekte transferiert werden. Dabei hilft ein Hilfskonstruktor der JPA, die sogenannten Constructor Expressions.
Um diese einfach zu verstehen, an dieser Stelle ein kleines Tutorial zum Verständnis.
Wie immer muss die Basis für das Projekt geschaffen werden. Die Grundlage für das Tutorial bildet:
Begonnen wird mit dem Einrichten des Workspaces. Dazu wird ein Projektordner erstellt und in diesen die entpackte Datenbank kopiert. Dies ist für den weiteren Verlauf des Einrichtens wichtig.
In diesem Ordner befinden sich sowohl die Datenbank, als auch die notwendigen Treiber.
Im zweiten Schritt wird ein JPA Projekt mit Eclipse angelegt.
Die Voreinstellungen können komplett übernommen werden. Nur der Name muss angegeben werden.
Im nächsten Schritt wird die Verbindung zur Datenbank und die eigentliche JPA Implementierung konfiguriert. Da es ein Quick & Dirty Tutorial ist, wird hier auf eine herunterladbare Bibliothek als JPA Implementierung verwiesen.
Als Treiber wird der vorher in den Projektordner kopierte Treiber gewählt.
Die Verbindungsdetails können aus den Defaulteinstellungen übernommen werden.
Somit sollte einer erfolgreichen Verbindung nichts im Wege stehen.
Nach dem Erstellen des Projektes müssen sowohl der Treiber, als auch die JUnit4 Bibliotheken dem Projekt hinzugefügt werden, so dass sich der folgende Aufbau ergibt.
Um später ohne Probleme eine Verbindung mit der Datenbank einzugehen, müssen die Eigenschaften der peristence.xml geringfügig modifiziert werden.
Die Einstellunge sorgen dafür, dass zum einen die Details für die Verbindung bekannt sind und zum anderen die Tabellen vor jedem Test wieder neu aufgesetzt werden.
Die Struktur der Klassen wird für den Test bewusst einfach gehalten:
Der Testfall führt nun unterschiedliche Aufgaben durch. Als erstes wird ein EntityManager erstellt, welcher für den Aufbau der Transaktionen und die Datenbankinteraktion vorhanden sein muss.
Im zweiten Schritt wird initial ein Employee erzeugt und sichergestellt, dass dieser auch in der Datenbank gespeichert worden ist.
Nun kommt der wichtige und spannende Teil. Das direkte Erstellen der DTOs aus der JPA-Query. Das Ergebnis der Query entspricht dem Typen, der übergeben wird. Dabei muss der zu erstellende Typ weder gemappt sein, noch sonstwie mit der Datenbank verknüpft werden.
Einzig und allein muss der entsprechende Konstruktur mit den übergebenen Attributen vorhanden sein.
Zugehöriger Konstruktor:
Das funktioniert natürlich auch für multiple Parameter.
Die Assertions stellen an dieser Stelle sicher, dass es sich auch wirklich um die entsprechenden Objekte handelt und nicht heimlich, still und leise die eigentliche Entität ausgelesen wird.
Wie auf der Konsole zu erkennen ist, handelt es sich auch wirklich um die entsprechenden DTOs.
Nützlich, wenn man sich das hin und her mit dem Konvertieren sparen möchte.
Um diese einfach zu verstehen, an dieser Stelle ein kleines Tutorial zum Verständnis.
Wie immer muss die Basis für das Projekt geschaffen werden. Die Grundlage für das Tutorial bildet:
- Eclipse
- EclipseLink 2.10 (Helios) als JPA 2.0 Implementierung
- JUnit4
- HSQLDB als Datenbank
Begonnen wird mit dem Einrichten des Workspaces. Dazu wird ein Projektordner erstellt und in diesen die entpackte Datenbank kopiert. Dies ist für den weiteren Verlauf des Einrichtens wichtig.
In diesem Ordner befinden sich sowohl die Datenbank, als auch die notwendigen Treiber.
Im zweiten Schritt wird ein JPA Projekt mit Eclipse angelegt.
Die Voreinstellungen können komplett übernommen werden. Nur der Name muss angegeben werden.
Im nächsten Schritt wird die Verbindung zur Datenbank und die eigentliche JPA Implementierung konfiguriert. Da es ein Quick & Dirty Tutorial ist, wird hier auf eine herunterladbare Bibliothek als JPA Implementierung verwiesen.
Im folgenden Schritt wird ein neues Connection-Profile angelegt. Hier wird die Verbindung zur HSQLDB festgelegt.
Die Verbindungsdetails können aus den Defaulteinstellungen übernommen werden.
Somit sollte einer erfolgreichen Verbindung nichts im Wege stehen.
Nach dem Erstellen des Projektes müssen sowohl der Treiber, als auch die JUnit4 Bibliotheken dem Projekt hinzugefügt werden, so dass sich der folgende Aufbau ergibt.
Um später ohne Probleme eine Verbindung mit der Datenbank einzugehen, müssen die Eigenschaften der peristence.xml geringfügig modifiziert werden.
Die Einstellunge sorgen dafür, dass zum einen die Details für die Verbindung bekannt sind und zum anderen die Tabellen vor jedem Test wieder neu aufgesetzt werden.
Die Struktur der Klassen wird für den Test bewusst einfach gehalten:
- Employee [Entität innerhalb der Datenbank]
- EmployeeFirstnameDto [Einfaches DTO für die Darstellung des Vornamens]
- EmployeeFullnameDto[Einfaches DTO für die Darstellung des gesamten Namens]
- ConstructorExpressionsTest [JUnit-Test für die Ausführung]
Der Testfall führt nun unterschiedliche Aufgaben durch. Als erstes wird ein EntityManager erstellt, welcher für den Aufbau der Transaktionen und die Datenbankinteraktion vorhanden sein muss.
Im zweiten Schritt wird initial ein Employee erzeugt und sichergestellt, dass dieser auch in der Datenbank gespeichert worden ist.
Nun kommt der wichtige und spannende Teil. Das direkte Erstellen der DTOs aus der JPA-Query. Das Ergebnis der Query entspricht dem Typen, der übergeben wird. Dabei muss der zu erstellende Typ weder gemappt sein, noch sonstwie mit der Datenbank verknüpft werden.
Einzig und allein muss der entsprechende Konstruktur mit den übergebenen Attributen vorhanden sein.
Zugehöriger Konstruktor:
Das funktioniert natürlich auch für multiple Parameter.
Die Assertions stellen an dieser Stelle sicher, dass es sich auch wirklich um die entsprechenden Objekte handelt und nicht heimlich, still und leise die eigentliche Entität ausgelesen wird.
Wie auf der Konsole zu erkennen ist, handelt es sich auch wirklich um die entsprechenden DTOs.
Nützlich, wenn man sich das hin und her mit dem Konvertieren sparen möchte.
Abonnieren
Posts (Atom)