SDDM also comes with a good number of scripts written in JRuby - the JVM implementation of the Ruby language. But to use the JRuby scripts, or scripts written in some other compliant scripting language, you need to copy the Java library(s) for that language to your SDDM classpath. The easiest way to find a good place to put them is to go to the Help/About page, select the Properties tab, and find the property named java.ext.dirs:
With SDDM shut down, put the library in one of the directories listed in this property. Then you can re-start SDDM. Mine is in %SDDM_HOME%\jdk\jre\lib\ext where SDDM_HOME is the root directory where you installed SDDM. This information, and much of what I have learned about scripting SDDM, came from Dave Schleis, especially his blog post, Data Modeler Scripting-101-Lets start at the very beginning.
DDL Transformation Script for Journal Table
What I needed was a script to generate the DDL to create a journal table behind one of my tables, plus the database triggers to automatically write to the journal table every time DML is executed against the base table. SDDM happens to come with a script, written in JavaScript (for Nashorn) to do this. If you are designing an Oracle database, you may be able to use this script out of the box. But I am writing for a SQL Server database, and while the CREATE TABLE for the journal table is almost identical, triggers in SQL Server are VERY different. Not only are they written in T-SQL, which is quite different from PL/SQL, but triggers all run as statement level triggers, not row level triggers. So I was glad to have the original script as an example, but I needed to do major changes.
Writing scripts in Groovy
Now, I could have kept the script in JavaScript, but I don't know that language very well. I don't know Ruby very well either. Dave Schleis's favorite language is Apache Groovy which like JRuby does support the JSR-223 standard, so some of his examples are in Groovy. And I've gotten familiar with Groovy because of my past experience with Oracle Application Development Framework (ADF). ADF's Model component, ADF Business Objects, can be extended with scripts written in Groovy. So I decided to write my DDL Transformation for SQL Server Journal Tables in Groovy.
To write SDDM scripts in Groovy, all you need to do is copy the Groovy library to the SDDM classpath as I described above. Download a copy of Groovy from http://www.groovy-lang.org/download.html. While the latest stable version of Groovy is 2.5, it does not contain the library needed to support JSR-223. So download the binary for the latest 2.4 version - I downloaded apache-groovy-binary-2.4.15.zip. The library you want is groovy-all-2.4.15.jar, found in the "embeddable" directory.
To write scripts, select Tools/Design Rules and Transformations... from the SDDM menu. The kind of script I wanted to write is a Table DDL Transformation, which can be run when exporting the DDL for your Relational/Physical design. Choose the Relational Model for your script. Then you will see:
I have already added my script. Notice that there are four possible scripts for each script set - one to add DDL code before the CREATE TABLE commands, one to actually replace the CREATE TABLE commands, one to add code after the CREATE TABLE, and one to add code at the end of the DDL for all the tables being exported. You don't need to use all four, and in fact, my journal table code is only for After Create. You won't be able to select a scripting engine until after you start writing the script - I'm not sure why. So start by just adding a comment or a few spaces. I started by selecting the Journal tables script that comes with SDDM and copying it, then pasting it into my new script. Then pick a scripting engine. If you have correctly added the Groovy library to the classpath, "Groovy Scripting Engine" should be one of the choices. Warning - there is currently (18.1 for me) a bug in SDDM where SDDM doesn't save the scripting engine choice for Groovy Scripting Engine. Oddly, it does for Oracle Nashorn, the default, and for JRuby. The work-around is to go into dr_custom_scripts.xml find the reference to your script and change the engine attribute. I'd make a back-up of this file first.
So in the next post, I'll go through the code for my script and talk a little about testing it.
