Für eigene Projekte und insbesondere auch für das Einarbeiten in fremde Projekte ist es da sehr nützlich, wenn man genau sieht, was auf der Datenbank so alles passiert.

Hier hilft das Tool log4jdbc-remix sehr gut weiter, weil es sowohl alle Anfragen als auch die Ergebnisse mitschreiben kann. Es lassen sich auch eigene LogFormatter integrieren und selbst der Umgang mit mehreren Datenbanken ist in der neusten Release 0.2.8 kein Problem.

Da ich selbst auch schon über ein paar kleinere Probleme gestolpert bin, kann ich ausserdem den guten Entwickler-Support unterstreichen: Jedesmal hat Tim, der Owner des Projekts, sehr schnell reagiert und das Problem beseitigt oder einen Patch übernommen.

Mit dem Kauf der Lampen ging allerdings der Spass erst los …Bei uns im Haus gibt es nämlich viele solcher Halogenlampen als Einbauleuchten in der Decke. Das erste, was ich feststellen mußte, war, dass die neuen LEDs die Normmasse gar nicht einhalten.

Was bei manchen Leuchten nicht sonderlich stört, ist bei Einbauleuchten u.U. fatal, weil die LEDs schlicht nicht reinpassen.

Das nächste Ärgernis ist der eigentlich erwünschte geringe Energieverbrauch! Meinst sind bei Halogenbeleuchtungen nämlich elektronische Trafos verbaut (Schaltnetzteile), die eine gewisse Mindestleistungsabnahme benötigen. Wird zuwenig Strom verbraucht, dann beginnt die Spannung zu schwanken und die Netzteile laufen gefahr mit der Zeit zerstört zu werden.

Eingebaute LED Leuchtmittel quittieren solche Spannungsschwankungen mit einem hässlichen Flackern, schlimmer wie jede Neonröhre. Also musste ich auch noch die Netzteile austauschen, die freilich in der Zwischendecke versteckt und nur mit erhöhtem Aufwand zu erreichen waren.

Bleibt noch, dass LEDs immer noch nicht dimmbar sind und auch die Lichtfarbe – auch die sogenannten Warmweissen – leider nicht mit dem angenehmen Licht einer Halogenlampe mithalten können.

Soviel zum Thema Ernergiesparlampen / LEDs.

Leider fühlt sich auch Hector in keiner Weise so an wie man es von konventioneller Datenbank-Programmierung gewohnt ist. Das Java-API ist nach meinem Geschmack “gewöhnungsbedürftig” um es einmal diplomatisch auszudrücken.

Dabei gibt mit Spring-JDBC (oder neuerdings mit Spring-Data) längst gute Beispiele wie man es gut machen kann. Jetzt kann man natürlich einwenden, dass diese “alten” Ansätze für SQL-Datenbanken gemacht sind und sich daher nicht für NoSQL Lösungen eignen, aber wenn man zweimal hinsieht, dann merkt man schnell, dass das gar nicht stimmt.

Der Unterschied bei der Sicht auf die Daten besteht meiner Meinung nach im Wesentlichen im Datenmodell, oder in der Art wie man zum Datenmodell kommt: entweder klassisch relational und normalisiert, oder Abfrage-Orientiert und de-normalisiert.

Wenn das Datenmodell aber steht, ließe sich mit den Daten eigentlich genauso arbeiten wie mit SQL-Datenbanken: über eine Abfrage-Sprache. Im Falle von Cassandra ist das CQL. Parallelen gibt es mit Keyspace = Database, ColumnFamily = Tabelle, und Column / Row genug. Die Einschränkungen / Erweiterungen con CQL sind eben der Datenbank geschuldet (z.B. kein Join) und stören erst mal nicht, wenn man sich für das NoSQL Modell entschieden hat.

Jetzt gibt es mit Cassandra-JDBC sogar einen JDBC-Treiber für Cassandra, der auch CQL über JDBC in jeder Java-Anwendung verfügbar macht. Man sollte also meinen alles Handwerkzeug in Händen zu halten, um “vernünftig” arbeiten zu können.

Leider ist dem im aktuellen Release 1.0.5 (Dez 2011) von Cassandra nicht so.

Die Umsetzung ist etwas lückenhaft, so dass praktisch bei jeder anderen Anwendung (außer “Hello World”) Probleme auftreten.

Spalten sind nicht löschbar

Will man eine Spalte löschen, dann wird man im normalen SQL ein UPDATE … Feldname = NULL verwenden, was aber beide Spaltenorientierten Cassandra mit CQL nicht funktioniert. Dort muss stattdessen die Spalte selbst gelöscht werden mit DELETE Column(s) FROM ColumnFamily WHERE …

Unnötig umständlich wie ich finde. Man ist gezwungen UPDATES auf Rows in ein UPDATE und ein DELETE Statement aufzuspalten, wenn man einen Teil der Spalten löschen will. Gerade weil Cassandra aber kein festes Schema mit beliebig vielen Spalten, die auch nicht notwendigerweise gefüllt sein müssen, unterstützt, ist dies doppelt ärgerlich.

Selects auf NULL-Spalten funktionieren nicht

Wie schon erwähnt wird man in einer Cassandra Persistenz sicher häufig auf Rows treffen, bei der nicht alle Spalten mit Werten belegt sind. Statt bei einer CQL Anfrage dann aber NULL, oder zumindest in der JDBC Darstellung NULL bzw. den passenden Default zu liefern, stolpert man über eine Exception. Man kann gar keine Spalten abfragen, die nicht gesetzt sind.

Unzureichende Expression-Language

Cassandra kennt zwar bestimmte Typen Spalten. Allerdings liefert CQL kaum ausreichen Ausdrucksmöglichkeiten mit diesen Typen umzugehen. Man kann nicht einmal einen Timestamp erzeugen, ausser den nackten Long-Wert direkt einzugeben, um nur ein Beispiel zu geben. Dies erschwert die Formulierung von Abfragen wiederum unnötig. Man hätte leicht bestehende Implementierungen von ELs adaptieren können, um halbwegs verwendbare Ausdrücke in CQL einsetzen zu können.

PreparedStatements funktionieren nicht

In JDBC ist es eigentlich der Normalfall PreparedStatements zu nutzen. Nicht nur weil man dem Server Gelegenheit gibt, die Anfragen zu optimieren, auch Injection wird damit wirkungsvoll verhindert. Leider unterstützt Cassandra 1.0.5 solche Anfragen bislang nicht. Der JDBC-Treiber bietet sie dennoch an.

Wie man in der Beschreibung und im Quellcode nachlesen kann, werden die Bindings jedoch schon auf der Clientseite aufgelöst und dann zum Server geschickt. Damit könnte man leben, wenn das wenigstens funktionieren würde. Leider ist auch hier die Implementierung fehlerhaft, sodass oft genug die Bindung schlicht falsch ist und der Server die Anfrage mit einem Fehler quittiert.

Fazit

Will man Cassandra einsetzen, hat man sich so an das eine oder andere zu gewöhnen (oder wieder zu gewöhnen). Und damit meine ich nicht in erster Linie die Art der Datenmodellierung. Ich jedenfalls fühlte mich in mancher Hinsicht um eine paar Jahre in die Vergangenheit zurück versetzt, als man mit Oracle noch per Oracle Call Interface (OCI) sprechen musste. Aber wenns denn Cassandra sein muss …

Das Update von Serendipity auf die neuste Version war eh überfällig, also warum nicht gleich umsteigen auf WordPress. Sieht einfach hübscher aus und kann mehr.

Leider ging der Import der Daten nicht so einfach wie gedacht.

Zwar gibt es hier von Snowulf einen Importer und noch ein Update zur 1.5 hier. Aber zum einen muss man das Readme genau lesen und sich trauen, das SQL direkt anzuwenden auch wenn die WP Version nicht mehr stimmt, zum anderen sind dann immer noch nicht alle Inhalte mirgiert.

Der erste Importversuch wurde gleich mittendrin abgebrochen, weil der Nutzernamen im Import schon vergeben war und das Import-Script das nicht abfängt. Leider waren die Kategorien aber schon importiert.

Dann wurde die mehrsprachigen Artikel nicht übernommen. Okay das waren hier nur 4 und da konnte man das Englische manuell rüberziehen.

Aber es geht auch die Hierarchie der Kommentare verloren. Und die Formatierung von Quellcode geht in WP auch ganz anders (zum Glück aber besser, nur umstellen muss man trotzdem).

Noch eine gute Quelle ist hier zu finden. Dort wird auch beschrieben was man tun muss damit die alten Permlinks wieder funktionieren. Allein die Post-IDs konstant zu halten reicht natürlich nicht, weil die Links von s9y ganz anders aussehen und sich mit den Standard-Einstellungen von WP auch nicht nachbilden lassen.

Leider nutzt der Autor zum Umschreiben der URL eine Konfiguration lighttpd, was bei Apache2 natürlich nicht passt. Mit etwas PHP bekommt man das aber auch in der Griff. Nur die Feed-URL sind hier jetzt noch nicht gerade gezogen, aber ich befürchte soviele Abbonnenten hab ich gar nicht

Naja jetzt ist’s geschafft und vielleicht lebt dadurch das Blog wieder etwas auf.

der neue Polanski Film “Der Gott des Gemetzels”. Herrlich anzuschauen, absolute Empfehlung ein “Kammerspiel” im Kino mit tollen Charakteren, einer langsamen Entwicklung hin zum kompletten “Gemetzel” wirklich sehenswert. Von Constantin Film.

Die Persistenz ist – nach dem neusten Trend “back to the roots” – nur noch mit dem JdbcTemplate von Spring gemacht. Da kann man wieder richtiges SQL schreiben und weiß auch genau was passiert (bei Hibernate war ich mir nicht immer so ganz sicher).

Als es dann ans Testen ging und ich mir Gedanken um die Testabdeckung machte, fiel mir auf, dass das was bei if-Anweisungen oder bedingter Zuweisung im Java-Code als “missed 2 of 4 branches” an gemeckert wurde, an vielen Stellen in den Where-Clauses der SQL-Statements genauso auftritt.

Die Coverage in Java war also bei mancher Methode auf 100% aber das SQL-Statement ließ viele Varianten von ResultSets zu je nach dem, was man für Testdaten verwendet und welche konkreten Parameter man bindet.

Wie also läßt sich die SQL-Coverage messen?

SQL tracen

Zunächst einmal ist es nützlich die SQL-Statement mitschrieben zu lassen, die tatsächlich ausgeführt werden inklusive der aktuell gebundenen Parameter. Hierfür kann man Tools wie http://code.google.com/p/log4jdbc-remix/ bzw. http://code.google.com/p/log4jdbc/ verwenden. Diese JDBC-Treiber arbeiten als Proxy und werden einfach “zwischen” die Applikation und den echten Treiber “gehängt”. Dadurch wird es einfach möglich alle SQL-Statements die man bei Ablauf einer Testsuite an die Datenbank schickt mitzuschreiben.

Aber leider weiss man damit immer noch nicht, ob man nun alle möglichen “Zweige” aller Where-Bedingungen aller SQL-Statements durchlaufen hat.

SQL Rules und QAShrink

SQL Rules und QAShrink sind zwei Tool, die genau darüber Aufschluss geben können. Sie sind in der Lage ein gegebenes SQL-Statement zu analysieren nach der “Full Predicate Coverage” Methode. Es werden also Regeln erzeugt, die alle Verzweigungen oder Varainten die ein SQL-Statement erzeugen kann, berücksichtigt.

Dabei werden nicht nur Where-Bedingungen in Betracht gezogen, sondern natürlich auch Joins oder Group By-Klauseln. SQLRules zeigt zu einen einzelnen Statement diese Rules an, so dass man sich anschauen kann, welche möglichen “Pfade” zur Ergebnisfindung durchlaufen werden können.

Regeln anwenden

Im nächsten Schritt lassen sich diese Regeln dann gegen einen Testdatenbestand anwenden / testen. Als Ergebnis bekommt man eine Aussage, ob die betreffende Regel verwendet wurde oder nicht, also ob dieser Pfad bei den zugrunde gelegten Daten durchlaufen wurde oder nicht. Das ist genau die SQL-Coverage die man braucht.

Das andere Tool QAShrink kann dieses Prinzip gleich auf eine ganze Liste von SQL-Statements anwenden. Es erzeugt dann Aussagen bzgl. der Coverage der SQL-Statements und der Vollständigkeit bzw. der Redundanz der Testdaten.

Auf diese Weise kann man also ziemlich schnell herausfinden, welche Testdaten überflüssig und welche noch zu ergänzen sind, um – bei gegebener Liste der SQL-Statements – die SQL-Coverage möglichst hoch zu machen.

Zusammenfassung

Das Vorgehen zum Erreichen einer möglichst hohen SQL-Coverage läßt sich also so zusammenfassen:

1. Mit einem JDBC-Proxy Treiber erzeugt man eine Liste von konkreten SQL-Abfragen, die von einer TestSuite mit hoher Code-Coverage erzeugt wird.
2. Die Liste der SQL-Statemant füttert man in QAShrink und läßt sie gegen den gleichen Testdatenbestand wie die TestSuite laufen.
3. Anhand der Ergebnisse kann man den Testdatenbestand so lange um Datensätze ergänzen, bis eine optimale SQL-Coverage erreicht ist.

Links zu den Tools:
http://in2test.lsi.uniovi.es/sqltools/sqlrules/
http://in2test.lsi.uniovi.es/sqltools/qashrink/

Ich selbst bin auch nicht unbedingt ein Freund von „graphischer Programmierung“ oder geschwätzigem XML, was fast schon Programmiersprache sein will, aber in fast jeder
Hinsicht unhandlicher ist als eine „normale“ Programmiersprache wie Scala oder Java.

Aus diesem Grund reizte mich die Idee einen alternativen Ansatz zu versuchen. Da ich, wie gerade schon erwähnt, kein Freund von „in XML programmieren“ bin, sollte die
Beschreibung des „Prozesses“ – das Prozessmodell – in Java erfolgen.

Hier bietet sich das State-Pattern an, welches eine Prozessablauf mit Hilfe von Zustandsobjekten und einem Kontext beschreibt. Konkret werden also nur Interfaces bzw. abstrakte Basisklassen benötigt, die von einem konkreten Prozess implementiert
werden. Dazu der „Contract“ der den Ablauf / die Semantik beschreibt und schon kann ein „Prozess“ statt in XML in Java geschrieben werden.

Allerdings kann man nun einwenden, dass das normale Ausführungsmodell einer JVM mit Threads nicht die gleichen Vorteile bietet wie eine Workflow-Engine.

Inspiriert von den Ansätzen von Dalma und Javaflow oder auch den Arbeiten von Doug Lea (FJTasks) ist aber auch auf einer Java VM mehr möglich, als einfach für jeden Prozess
und jede seiner Nebenläufigkeiten einen neuen Thread zu starten.

Würde man das tun, wären diese bei den eingangs genannten Anforderungen sicher bald aufgebraucht (viele Prozessinstanzen, womöglich viele davon nur wartend).

Auch mit der Skalierbarkeit haben viele Workflow-Engines gewisse Probleme, weil sich die Arbeit schlecht über einen Cluster verteilen läßt. Aber auch hier gibt es im Standard
Java gute Lösungansätze, wie z.B. GridGain.

Ein weiterer Aspekt, den Workflow-Engine bedienen, ist Prozesspersistenz. Prozesse, die auf der Engine ablaufen, lassen sich persistieren. Damit ist der Ablauf unterbrechbar, wiederherstellbar und nachvollziehbar. Wenn allerdings Prozesse normale durch normale Java-Objekte dargestellt werden, dann lassen sie sich auch mit einfachen ORM Mitteln persistieren.

Zu guter letzt sind die meisten Prozesse immer auf irgendwelche Services angewiesen, die von ihnen aufgerufen werden, oder Calls an die Prozesse absetzen. Hierzu soll
für das Java basierende Prozessmodell ein Container /Application-Server zum Einsatz kommen. Meine Wahl fiel auf Spring, wobei sicher auch andere Lösungen denkbar wären.

Das Rezept für meine Workflow-Engine lautet also:

• Prozesse sind Java-Klassen, die nach dem State-Pattern einen Ablauf implementieren.

• Diese Klassen sind typischerweise Spring-Beans, die vom Container „Services“ konsumieren.

• Die Klassen sind Serializable und damit „Remoting“-fähig für GridGain.

• Die Klassen tragen (optional) Persistenz-Annotationen, welche die Engine dafür nutzt den Prozesszustand zu persistieren.

Heraus kommt eine Lösung,

• die hochskalierbar ist, weil Prozesse über GridGain auf einem Cluster von Nodes verteilt werden können.

• die den gewohnten Komfort einer IOC-Umgebung genießt, bei der nach Belieben „Services“ genutzt werden können (natürlich nicht nur Webservices).

• die den Prozesszustand nach jedem Prozessschritt mit Hilfe eines Persistenzproviders wie z.B. Hibernate persistiert.

• die Prozesse einfach als Java-Programm beschrieben, welches mit einfachsten Mitteln und voller IDE Untersützung entworfen werden kann.

Besonders den letzten Punkt möchte ich noch einmal unterstreichen: Man kann es gar nicht hoch genug bewerten, wie viele Vorteile sich allein dadurch ergeben, dass man in
der gewohnten Umgebung arbeiten kann:

• kein Lernen einer Prozessbeschreibungssprache (in XML).

• alle Möglichkeiten und Konstrukte einer Programmiersprache wie Java.

• die gewohnte IDE.

• simples Debuggen und Testen (noch besser zu unterstützen durch Mocks und eine spezielle Engine, die ein lokales Debuggen direkt ermöglicht).

• Einfachstes Wiederverwenden von vorhandenem Code oder vorhandenen Services (meist sind keinerlei „Wrapper“ oder „Adapter“ notwendig).

Wie die Lösung konkret aussieht, werde ich wohl heute nicht mehr zusammenschreiben, deshalb wird’s demnächst hier ne Fortsetzung geben …

]]> http://cogito-ergo-blog.de/blog/2009/07/28/workflow-engine-einmal-anders/feed/ 0 http://cogito-ergo-blog.de/blog/2008/09/30/jboss-seam-mit-mondrian-olap/ http://cogito-ergo-blog.de/blog/2008/09/30/jboss-seam-mit-mondrian-olap/#comments Tue, 30 Sep 2008 21:29:19 +0000 steve40 http://euve3303.vserver.de/stefan/blog/?p=40 Weiterlesen →]]> Der Mondrian OLAP Server, der seit einer Weile zur Pentaho-Suite gehört, kann mit einer recht leistungsfähigen Implementierung von Data-Cubes und der MDX-Abfragesprache aufwarten.

Allerdings kommt die mitgelieferte Oberfläche etwas altbacken daher. JPivot und auch das Charting machen für meine Begriffe nicht viel her. Auch die eingesetzte Web-Technologie ist eher von gestern: JSPs und Taglibs oder ein selten genutztes Web Framework WCF.

Da wurde bei mir schnell der Wunsch wach, Mondrian in JBoss SEAM zu integrieren und die Chart evtl. mit Open Flash Chart etwas aufzupeppen.

Der folgende Artikel zeigt den ersten Versuch, ein Anfang ist also gemacht.

Taglib gegen Components

Der erste Ansatz war die alte JSP-Taglib, die unter Faclets sowieso nicht zu nutzen wäre, gegen eine JSF-Componente einzutauschen. Im zweiten Schritt soll dann eine SEAM-Componente hinzu kommen.

Die Mondrian Taglib besteht im Kern aus drei Klassen:

1. QueryTag
2. TransformTag
3. ResultCache
4. DOMBuilder

1 und 2 sind echte JSP-Tags, das erstere nimmt die Query entgegen und das zweite rendert mit Hilfe von XSLT daraus HTML-Tabellen.

3 und 4 sind Hilfsklassen zur Resourcenverwaltung und zum Erzeugen eines DOM-Trees aus dem Qurey-Result. Der ResultCache sollte in der Form unter SEAM wohl gar nicht existieren, sondern in eine SEAM-Componente übergehen, aber im ersten Schritt habe ich ihn fast unverändert übernommen.

Neu zu bauen ist eine JSF UIComponent, die an Stelle der JSP-Tags die Anfrage entgegen nimmt und das Ergebnis darstellt. Hierzu leitet man die neue Componente von UIOutput ab, definiert die benötigten Properties und überschreibt zum Rendern der Ausgabe “encodeEnd”.

Die Component (oder besser deren Type) registriert man in einer Facelets-Taglib “mondrian.taglib.xml” und die Component-Class in der face-config.xml. Da die neue Facelets-Taglib nicht im META-INF eines Jars liegt, macht man sie Facelets explizit durch den Context-Parameter “FACELETS.libraries” in der web.xml bekannt.

Test-Project mit SEAM

Als nächstes setzt man mit “seam create-project” eine SEAM Project auf, fügt wie oben beschrieben, die neue Componente ein und baut einen View, der die neue Componente instanziiert.

Damit Mondrian funktioniert, muss man dem SEAM-Project noch einige Dependecies von Mondrian hinzufügen. Bei der von mir verwendeten Mondrian Version (siehe unten) sind dies:

• eigenbase-xom.jar
• eigenbase-res.jar
• eigenbase-properties.jar
• mondrian.jar
• olap4j.jar
• commons-dbcp-1.2.jar
• commons-pool-1.2.jar
• commons-vfs.jar
• commons-math-1.0.jar
• javacup.jar

Diese trägt man zusätzlich in die von seamgen erzeugte Datei “deployed-jars-ear.list” ein und kopiert sie nach “lib” im Projekt-Verzeichnis, so werden sie von SEAM beim Deployment automatisch berücksichtig.

Desweiteren muss der von Mondrian verwendete JDBC-Treiber auf dem Classpath verfügbar sein. Dieser kann ggf. auf dem Container selber deployed werden (jboss/lib).

Weitere Resourcen

Nun fehlt nur noch wenig bis zur ersten Abfrage:

1. Mondrian benötigt eine Property-Datei mondrian.properties auf dem Classpath. Diese wird einfach aus dem Mondrian-Demo WAR kopiert und auf die Classpath-Root gelegt (neben seam.properties). Damit auch diese Datei beim Deployment berücksichtigt wird, trägt man sie am besten in die build.xml ein.
2. Das Mondrian-Modell (hier im Beispiel foodmart.xml) muss ebenfalls (am besten auch über den Classpath) auffindbar sein. Gleiches Spiel wie eben.
3. Der connectString zum Mondrian-Server muss als Context-Parameter in der web.xml eingetragen werden.
4. Da die Componente (vorerst) wie das alte Tag ein XSL-Stylesheet verwendet, um das Ergebnis nach HTML zu wandeln, muss auch das Stylesheet als Classpath-Resource ladbar sein.

Der Pfad zum Modell im ConnectString muss übrigens mit “res:” beginnen, damit Mondrian, was das VFS von Apache Commons nutzt, die XML-Resource auch findet.

Versionen

Die Versionen, die genutzt habe, sind: JBoss 4.2.2.GA, Seam 2.0.2.SP1 und Mondrian-3.0.4.11371-embedded. Das komplette Projekt gibt demnächst hier zum Download.

Ausblick

Wie schon in der Einleitung geschrieben, reizt mich vor allen das Charting mit Open Flash Chart zu machen. Eine weitere Chart-Componente muss also her, die Ergebnisse aus Mondrian direkt als Chart rendern kann.

Weiterhin ist natürlich die Resourcen-Verwaltung in dieser ersten Fassung nicht gerade SEAM-like, werde ich noch ändern. Und schliesslich ist die Componente natürlich etwas sehr statisch. In SEAM im RichFaces wünscht man sich ja was geAJAXtes wo der Drill-Down und das Pivoting nur so flutsch …

Mal sehn wann das nächste mal Zeit für sowas ist.

Das Archiv enthält ein komplettes Projekt (frisch mit seamgen erzeugt), ergänzt um alles was in diesem Artikel erwähnt ist. Wegen der Downloadgrösse fehlen lediglich alle *.class, alle *.jar und alle *.dat Dateien von der Derby-DB.

Wenn komplett gebaut und deployed ist, das sieht das ganze so aus:

BTW: An dieser Lösung ist nichts SEAM-spezifisch, alles geht natürlich auch mit Plain-JSF. Da ich aber immer mit Facelets arbeite, habe ich keine JSP-Tag Unterstützung vorgesehen.

Es wird zwar angeboten, wie bei One-To-Many, aber wenn „Add …“ gewählt wird, kann zwar ein neues Child angelegt werden, aber die Verbindung wird nicht
hergestellt.

Auch beim One-To-Many gibt es auf der Many-Side Einschränkungen: es kann nur ein Child per „Add …“ hinzugefügt werden. Weder wird das Zuordnen eines bereits
angelegten Childs ermöglicht, noch wird das Löschen angeboten.

Ausserdem ist die Doku nicht konsistent: Beim Domain-Mapping mit GORM heißt es:

„Grails supports many-to-many relationships by defining a hasMany on both
sides of the relationship and having a belongsTo on the side that owns the relationship“.

Richtig ist aber das belongsTo gehört auf die Child-Side, nicht auf die Parent-Side, so wie es auch im zugehörigen Beispiel ist.

Wichtig ist hier nämlich:

„The owning side of the relationship, in this case Author, takes
responsibility for persisting the relationship and is the only side
that can cascade saves across.“

Also nur die Parent-Side hat den Cascading-Save und somit sollte nur von dort aus geändert werden. Jedenfalls werden nur die von der Parent-Side ausgemachten
Änderungen ohne weiteres persistiert. Würde man von der Client-Side aus ändern, dann müßte die zugehörige Änderung im Parent explizit gesetzt und persistiert werden.

Um die Unterstützung für Many-To-Many in den mit Scaffolding generierten Views zu bekommen, sind die Templates anzupassen. Wie das geht beschreibt der folgende
Artikel.

Viel von den folgenden Codeschnipseln und Konzepten ist durch andere Artikel inspiriert (siehe Referenzen). Was hier zusätzlich dargestellt wird, ist die komplette Logik zu
generieren auch in den Controllern. Und zu guter letzt ist ein komplettes Beispiel beigefügt.

Der erste Schritt für eigene, angepasste Templates ist immer:

grails install-templates

Damit kopiert GRAILS die Standard-Templates lokal ins Projekt und benutzt fortan diese.

Dann sucht man im Verzeichnis src/templates/scaffolding das renderEditor.template. Dieses ist für das Erzeugen der Edit-Controls für die einzelnen Properties
einer Domain-Klasse zuständig.

Hier gibt es eine Methode „renderOneToMany“, die zunächst eine Liste der bereits
verknüpften Objekte mit Link auf deren „Show“-Url ausgibt und dann das schon bekannte „Add …“ anbietet. Dieses „Add“ wird durch folgende Zeile erzeugt:

if( property.oneToMany ) {
    pw.println
" <span
class=\"buttons\"><g:link
   controller=\"${property.referencedDomainClass.propertyName}\"
params=\"['${domainClass.propertyName}.id':${domainClass.propertyName}?.id]\"
action=\"create\"  class=\"create\">Add</g:link></span>"
 }
 if( property.isOwningSide() ) {
 	pw.println
" <span
class=\"buttons\"><g:link
controller=\"${property.referencedDomainClass.propertyName}\"
params=\"['${domainClass.propertyName}.id':${domainClass.propertyName}?.id,
'source':'${domainClass.propertyName}',
'class':'${property.referencedDomainClass.name}',
'dest':'${property.name}','callback':'link']\"
action=\"list\" class=\"save\">Assoc</g:link></span>";
 	pw.println
" <span
class=\"buttons\"><g:link
controller=\"${property.referencedDomainClass.propertyName}\"
params=\"['${domainClass.propertyName}.id':${domainClass.propertyName}?.id,
'source':'${domainClass.propertyName}',
'class':'${property.referencedDomainClass.name}',
'dest':'${property.name}','callback':'unlink']\"
action=\"list\" class=\"delete\">Remove</g:link></span>";
 }

Dadurch werden zusätzlich ein „Assoc …“ zum Verbinden und ein „Remove …“ angeboten, falls man von der „Owning-Side“ aus das Objekt editiert.

Somit kann man einerseits auch beim One-To-Many die Assoziation vom Parent aus direkt ändern. Aber – viel wichtiger – Many-To-Many funktioniert so endlich wie
gewünscht.

Um das Bild komplett zu machen, fehlen allerdings noch zwei Bausteine. Die neuen Buttons „Assoc“ und „Remove“ leiten zunächst beide zur „List“-Action der verknüpften Klasse weiter, somit wird der normale List-View verwendet, um das Element auszuwählen, welches verknüpft bzw. gelöscht werden soll. Damit diese Auswahl funktioniert, muss der List-View entsprechend erweitert werden. Im Template
list.gsp wird der „Show“-Link:

<g:link action="show" id="\${${propertyName}.id}">
	\${fieldValue(bean:${propertyName}, field:'${p.name}')}
</g:link>

fallweise durch einen „Choose“-Link ersetzt:

<g:if test="\${params.callback}">
  <g:link action="choose" params="\${params}" id="\${${propertyName}.id}">
      \${${propertyName}.${p.name}?.encodeAsHTML()}
  </g:link>
</g:if>

<g:if test="\${!params.callback}">
  <g:link action="show" id="\${${propertyName}.id}">
     \${${propertyName}.${p.name}?.encodeAsHTML()}
  </g:link>
</g:if>

Dies geschieht – wie man sieht – immer dann, wenn der Callback-Parameter gesetzt ist. Dieser Callback-Parameter wiederum beschreibt, was das „Choose“ jeweils bewirken soll, nämlich entweder ein „Link“ oder ein „Unlink“. Damit das so funktioniert leitet die „Choose“-Action im Controller jeweils auf die „Link“ oder „Unlink“-Action weiter.

Controller-Templates

Diese drei neuen Actions sind in den standardmässig generierten Controllern nicht vorhanden. Auch hier muss also das Template für den Controller angepasst werden.

Das Template für die Controller findet sich ebenso unter src/templates/scaffolding und heißt Controller.groovy. Hier werden am Ende die folgenden Zeilen eingefügt:

def choose = {
   redirect(controller:params.source,action:params.callback,params:params)
}

def link = {  def ${propertyName} = ${className}.get(params["${propertyName}.id"])
def toLink = grailsApplication.getClassForName( params["class"]).get(params["id"])
def d = params['dest']
  ${propertyName}."\${d}".add( toLink );
  render(view:'edit',model:[${propertyName}:${propertyName}])
}

def unlink = {  def ${propertyName} = ${className}.get(params["${propertyName}.id"])
def toUnlink = grailsApplication.getClassForName( params["class"]).get(params["id"])
def d = params['dest']
  ${propertyName}."\${d}".remove( toUnlink );
  render(view:'edit',model:[${propertyName}:${propertyName}])
}

Mit den „Link“ und „Unlink“ Actions kann jeder Controller zwischen beliebigen Domain-Klassen per „add“ und „remove“ Verbindungen erzeugen oder wieder entfernen.

Mit diesen drei – eigentlich minimalen – Änderungen funktionieren nun auch Many-To-Many Verknüpfungen mit GRAILS und Scaffolding out of the box.

Ausblick

Mit der vorgeschlagenen Lösung wird zur Auswahl beim Löschen und Verknüpfen der List-View „missbraucht“. Das ist nicht in jedem Fall optimal. Denkbar wäre auch ein eigener Choose-View, der eine schönere Darstellung hat evtl. auch im Popup-Fenster.

Eine weitere Unschönheit ist die Tatsache, dass der List-View auch beim Löschen immer alle Elemente anzeigt und nicht nur die aktuell verknüpften.

Referenzen

http://www.ibm.com/developerworks/web/library/j-grails04158/index.html

http://www.stainlesscode.com/site/comments/grails_one_to_many_scaffolding/

http://reverttoconsole.com/2008/06/grails-manytomany-gorm-example/

Beispiel

Download hier.

Damit sind sämtliche Notfall-CDs wie Knoppix oder BartPE, die noch im Schrank liegen, erst mal wertlos. Inzwischen booten aber auch alle Systeme von USB, so auch das neue Akoya mini Netbook. Also schnell das gewünschte BartPE System auf USB übertragen (siehe FAQ bzw. pe2usb.txt im aktuellen BartPE) und los.

Bootet auch, alles bestens, nur leider ist die Harddisk nicht zu finden: Die interne SATA-Platte braucht einen Treiber, damit WinXP darauf zugreifen kann.

Um dieses Problem zu umschiffen, mußte ich eine ganze Weile rumgoogeln, bis klar war wie’s geht, deshalb hier kurz die Schritt für Schritt Anleitung.

Ein BartPE zu erstellen erfordert immer die Installationsdateien von Windows mit SP2 oder grösser bereits “geslipstreamed”. Zum Glück hat der Akoya alle Installationsdateien im Windows-Verzeichnis bereits abgelegt (von CD holen geht ja nicht )

Schritt 1: BartPE herunterladen und konfigurieren

Einfach BartPE von http://www.nu2.nu/pebuilder/ herunter laden und Quellverzeichnis auf c:\windows einstellen.

Nach dem Durchlaufen des Builders pe2usb.cmd aufrufen mit dem Laufwerk des Sticks als Parameter (eventuell den Stick mit -f noch formatieren) und fertig. Nur leider noch ohne Zugriff auf die Platte.

Schritt 2: F6-Treiber “Diskette” erzeugen

Auf der Wiederherstellungspartition D: findet sich im Verzeichnis DRIVERS/AHCI eine Datei f6flpy32.exe, die nach dem Namen geraten die F6-Diskette erzeugen könnte. Ein Starten bewirkt aber leider gar nichts, nicht mal eine Fehlermeldung.

Mehr durch Zufall stellt man fest, dass das EXE ein WinImage Self-Extractor File ist (zeigt der Explorer-Tooltip) und das man dass mit WinRar auspacken kann. Heraus kommt ein Disketten-Image unschwer an der Dateigrösse von 1.440 KB zu erkennen.

Schritt 3: Dateien extrahieren

Leider kann man das Image auch nicht so leicht auf Diskette schreiben, weil sowas hat das Netbook natürlich schon dreimal nicht. Also muss man nur noch die Files aus dem Image extrahieren z.B. mit MagicISO und diese Files an die richtige Stelle ins BartPE Builder Verzeichnis kopieren und schon … geht’s.

Schritt 4: BartPE erweitern

Die richtige Stelle ist schnell gefunden. Im BartPE Verzeichnis Drivers in SCSIAdapter ein Verzeichnis “sata” anlegen und dort die Dateien der “F6″-Diskette rein, den PEBuilder nochmal durchlaufen lassen, alles auf den USB-Stick und Heureka!!! es geht.

Abkürzung

Den Inhalt der F6-Diskette findet ihr in diesem
Zip, so dass die Abkürzung einfach lautet:

• Zip in BartPE/Drivers/SCSIAdapter entpacken
• PEBuilder durchlaufen lassen
• mit pe2usb.cmd auf den Stick kopieren

Mit diesem BartPE kann man dann auch ganz schnell aus dem Windows XP Home Edition eine Professionell machen, wie das läßt z.B. in der CT 13/2008 auf Seite 188 nachlesen.