JAXenter

Masiar Ighani hat die für Grails 1.2 geplanten und nun verfügbaren Erweiterungen sehr schön im JAXenter-Artikel vorgestellt. Dem möchte ich die damals noch nicht bekannten Verbesserungen hinzufügen und einige Schwerpunkte herausheben. Die lesenswerten Release Notes finden sich hier.

Einfacher Upgrade

Der Upgrade von Grails 1.0.x auf Grails 1.1 war für manche Anwender mit mehr Aufwand verbunden als erwartet. Dafür ist der Umstieg von 1.1.x auf 1.2 bisher sehr flüssig verlaufen. Im Normalfall reicht ein einfaches "grails upgrade" Kommando. Einige wenige Probleme sind bekannt

Deklarative Abhängigkeiten

Eine Grails 1.2 Applikation braucht seine abhängigen Bibliotheken nicht mehr im "lib" Verzeichnis verwalten. Man kann die compile, test und runtime Abhängigkeiten wie in Gradle getrennt deklarieren und damit vor allem die transitiven Abhängigkeiten besser im Griff behalten. Das Prinzip ist wie bei Maven/Ivy, deren Repositories man direkt ansprechen kann, aber leichtgewichtiger. Diese neuen Einstellungen sind in "grails-app/conf/BuildConfig.groovy".

Schnellere Sichten

Die Groovy Server Pages (GSPs) werden nicht nur beim Deployment vorkompiliert und entlasten damit den PermGenSpace der JVM, die ganze Maschinerie wurde überholt und hat je nach Anwendungsfall einen bis zu Faktor drei höheren Durchsatz. Das alleine kann den Upgrade schon lohnen.

GORM defaults werden konfigurierbar

Das objekt-relationale Mapping von Grails (GORM) hat per Konvention einige Voreinstellungen, die meist günstig sind, aber manchmal auch im Weg stehen. So sind zum Beispiel alle Properties von Domänenklassen non-nullable, falls sie nicht in den constraints der Klasse als nullable:true markiert sind. Das kann gegebenenfalls dazu führen, dass man sehr viele dieser Markierungen anbringen muss, während nur wenige Properties von der Konvention profitieren.

Neu in Grails 1.2 kann man diese Konvention umstellen, indem man in "grails-app/conf/Config.groovy" dem Schlüssel "grails.gorm.default.constraints" einen neuen Wert zuweist. Das kann global geschehen, also für alle Domänenklassen oder nur für benamste constraints, die auch neu sind. Auf die gleiche Art kann man auch die Konventionen für das mapping übersteuern, z.B. für die caching Strategie.

Diese neue Eigenschaft sehe ich mit gemischten Gefühlen. Klar, so kann man Duplikation vermeiden und das ist gut. Andererseits wird mein Leben als Berater schwieriger, weil ich bei der Codeanalyse immer im Kopf behalten muss, welche Konventionen für das vorliegende Projekt gelten. Für Programmierer, die in ein neues Grails-Projekt einsteigen, gilt das gleiche. Ein Teil des Nutzens von "convention over configuration" wird so der höheren Flexibilität geopfert.

Named queries als Selektionsbasis

Die Möglichkeit, Datenbankabfragen zu benamsen war ja schon angekündigt. Sie hat aber noch eine besonders schöne Verwendbarkeit bekommen: als Basis für weitere Abfragen! In einer Anfragedefinition wie in folgender Domänenklasse

1. class Publication {
2. String title
3. Date datePublished
4. static namedQueries = {
5. recentPublications {
6. def recent = new Date() - 60
7. gt 'datePublished', recent
8. }
9. }
10. }

kann ich die named query einfach so verwenden

1. Publication.recentPublications.list()

Aber jetzt kommt der Trick: ich kann sie auch als Basis für eine weitere Selektionen nutzen:

1. Publication.recentPublications.findAllByTitle('Some Title')

Und das wird auf eine einzelne Datenbankabfrage abgebildet! Das ist sehr elegant und modular.