In a previous post we learned how we can use Hibernate native SQL queries in our Grails application. We can also execute custom SQL with Groovy SQL. We must create a new instance of
groovy.sql.Sql in our code to execute SQL code. The easiest way is to use a
javax.sql.DataSource as a constructor argument for the
groovy.sql.Sql class. In a Grails application context we already have a
DataSource and we can use it to inject it into our code. We must use the name
dataSource to reference the default datasource in a Grails application.
Sometimes we want to use Hibernate native SQL in our code. For example we might need to invoke a selectable stored procedure, we cannot invoke in another way. To invoke a native SQL query we use the method
createSQLQuery() which is available from the Hibernate session object. In our Grails code we must then first get access to the current Hibernate session. Luckily we only have to inject the
sessionFactory bean in our Grails service or controller. To get the current session we invoke the
getCurrentSession() method and we are ready to execute a native SQL query. The query itself is defined as a
String value and we can use placeholders for variables, just like with other Hibernate queries.
In our Grails applications we might have fields that need the same combination of constraints. For example we want all email fields in our application to have a maximum size of 256 characters and must apply to the email constraint. If we have different classes with an email field, like domain classes and command objects, we might end of duplicating the constraints for this field. But in Grails we can combine multiple constraints for a field into a single constraint with a new name. We do this in
grails-app/conf/Config.groovy where we add the configuration property
grails.gorm.default.constraints. Here we can define global constraints with can be used in our Grails application.
For many years now it has been good practice to write unit tests for your source-code.
And also to use test coverage reporting to see how much of your code is covered by tests.
Although line + branch coverage reporting is quite useful, it doesn’t tell you how good your unit tests actually are. Hence it’s even possibly to achieve 100% coverage without even a single assert in your tests.
Being interested in better ways of testing I attended the “Mutation testing” workshop during this years Joy of Coding conference.
Mutation testing is a radical different approach of executing and analyzing the result and coverage of your unit tests. Instead of measuring how much of your code is “accessed from” your unit tests it determines how much of your code is actually “tested by” your unit tests.
IntelliJ IDEA 13 added the Terminal tool window to the IDE. We can open a terminal window with Tools | Open Terminal…. To change the font of the terminal we must open the preferences and select IDE Settings | Editor | Colors & Fonts | Console Font. Here we can choose a font and change the font size: