Referential Integrity - Good or Bad?

In relational database world such as MySQL, PostgreSQL, Derby / JavaDB, and HSQLDB RDBMS there is Referential Integrity.

It's very useful to avoid consistency mistakes with foreign keys during operation.

It's useful when we live in *relational* world. But during development of a modular application and agile, frequent upgrades.. Is referential integrity helping or hindering productivity?

Consider an application that has a Customer table that has a column an refers to a Country table. Each deployment would have its own Customer table data. However, Country table is pretty much "shared" globally. Country table is never meant to be modified from the admin's perspective.

When there is a new country or modification, new version of application will be released, containing an update to Country table.

In old-school style of upgrades, Country table should be replaceable similar to how we replace files during upgrade, i.e. overwriting a file called countries.xml.

However, due to referential integrity, it's not possible to simply drop the table, recreate it with the data. We have to issue proper DML SQL statements to update the data from the "current" version (yes, we must detect what is the current version) to the new version.

All in the name of not breaking foreign key checks aka referential integrity.

Isn't RDBMS making simple things complex?

Deploying Eclipse BIRT Web Viewer to GlassFish 3.0.1 on Ubuntu 10.10

Eclipse BIRT is free / open source reporting engine for Java.

A commercial BIRT Report Server is available from Actuate (the company behind Eclipse BIRT). While Eclipse BIRT does not provide a free/open source reporting server, the BIRT Runtime provides a simple Eclipse BIRT Web Viewer.

Eclipse BIRT Web Viewer installation instructions for several Java EE application servers are here.

Here I share my own experience installing Eclipse BIRT 2.6.1 Web Viewer under GlassFish 3.0.1 Java EE Application Server :

1. Install package sun-java6-jdk dan ttf-mscorefonts-installer
Package ttf-mscorefonts-installer contains Microsoft fonts needed by some reports.


2. Install GlassFish 3.0.1+.
   When asked for JVM, enter: /usr/lib/jvm/java-6-sun

Run GlassFish. In Terminal, go to GlassFish directory and type:

bin/asadmin start-domain

Default GlassFish domain is : domain1

It will show something like:

tuneeca@geulis:~/glassfishv3$ bin/asadmin start-domain
Waiting for DAS to start ......
Started domain: domain1
Domain location: /home/tuneeca/glassfishv3/glassfish/domains/domain1
Log file: /home/tuneeca/glassfishv3/glassfish/domains/domain1/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

Now that GlassFish is running, you need to deploy Eclipse BIRT Web Viewer:

1. Download birt-runtime-*.zip from BIRT Downloads under BIRT Runtime.
   Inside this archive there is birt.war file.
   
2. Deploy birt.war through GlassFish admin ( http://localhost:4848/ ) or by copying birt.war to folder glassfish/domains/domain1/autodeploy/
   In the log file glassfish/domains/domain1/server.log (to follow this file, use tail -f ) you should see something like :
   [#|2010-11-22T16:55:54.411+0700|INFO|glassfish3.0.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|[AutoDeploy] Selecting file /home/tuneeca/glassfishv3/glassfish/domains/domain1/autodeploy/birt.war for autodeployment.|#]

3. Check BIRT Web Viewer is running at : http://localhost:8080/birt/

You will need two additional libraries, Apache Commons Logging and JDBC Driver for your database.

Commons Logging

Without this, you'll get an error: java.lang.NoClassDefFoundError: org.apache.commons.logging.LogFactory

birt.war needs Apache Commons Logging.

Copy the file commons-logging-1.1.1.jar to folder glassfish/domains/domain1/applications/birt/WEB-INF/lib
Then reload the webapp :

touch glassfish/domains/domain1/applications/birt/.reload

MySQL JDBC Driver

If you get an exception like:

An exception occurred during processing. Please see the following message for details:
Cannot open the connection for the driver: org.eclipse.birt.report.data.oda.jdbc.dbprofile.
    org.eclipse.datatools.connectivity.oda.OdaException ;
    java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

For MySQL:
Copy file mysql-connector-java-5.1.13.jar to glassfish/domains/domain1/applications/birt/WEB-INF/platform/plugins/org.eclipse.birt.report.data.oda.jdbc_[version]/drivers

For other databases, copy the appropriate JDBC driver(s).

Go to: http://localhost:8080/birt/

Now you should be able to run BIRT reports over the web, on GlassFish!

Compact anonymous inner classes in Scala

Scala programming language has a much more compact syntax for anonymous inner classes.

This code in Java:

import com.vaadin.ui.*;

home.addComponent(new Button("Manage Users", new Button.ClickListener() {
@Override
public void buttonClick(Button.ClickEvent event) {
panel.setContent(userManagementLayout);
}
}));

becomes this in Scala:

import com.vaadin.ui._

home.addComponent(new Button("Manage Users", (event: Button#ClickEvent) =>
    panel.setContent(userManagementLayout);
)));

Vaadin TouchKit and Google App Engine = Session expired / Out of sync errors?

I've been developing with Vaadin, Vaadin TouchKit (for Mobile UI), and Google App Engine... and getting a lot of these messages:

Out of sync Something has caused us to be out of sync with the server.
Take note of any unsaved data, and click here to re-sync.

Also session expired messages......

Any ideas / solutions / workarounds ?

I'm considering switching to JSF 2.0 + PrimeFaces ...

Gradle Build for Spring Framework and SLF4J without Apache Commons Logging

Gradle build system supports Transitive Dependency Management.

It's very useful when you depend on a library, say Spring Framework, that uses Apache Commons Logging (artifact commons-logging:commons-logging), but you want to use another library like SLF4J and want to exclude Commons Logging.

Here is the Gradle build to exclude the commons-logging transitive dependency.

repositories {
mavenCentral()
}

configurations {
compile
runtime
all*.exclude group: 'commons-logging' // this is where we exclude
}

dependencies {
compile group: 'org.springframework', name: 'spring-web', version: '3.0.5.RELEASE'
compile group: 'org.slf4j', name: 'slf4j-api', version: '1.6.1'
runtime group: 'org.slf4j', name: 'slf4j-jdk14', version: '1.6.1'
runtime group: 'org.slf4j', name: 'jcl-over-slf4j', version: '1.6.1'
}

// Example usage: Copy dependencies
// e.g. to the Google App Engine WEB-INF/lib directory
task copyDependencies << {
copy {
from configurations.compile
from configurations.runtime
into 'war/WEB-INF/lib'
}
}

Typecasting in Scala

In Java :

Car car = (Car)Vehicle.factory(Car.class);

(Of course, the above is a really bad example. But I can't think of a better one right now)

In Scala :

var car = Vehicle.factory(classOf[String]).asInstanceOf[Car];

So, there are two core class functions in Scala: classOf[C] and asInstanceOf[C]

Scala IDE Eclipse Plugin for Scala 2.8.1 Final Released

After four rounds of release candidates, Scala 2.8.1.final has been released, fixing a large number of bugs, and introducing some enhancements, in particular in Scaladoc.

Perhaps most importantly, this new release is completely binary compatible with 2.8.0.final. As has been the rule, it’s still necessary to update the Scala tooling for Eclipse to take advantage of the new Scala compiler and library version. Thankfully, the aforementioned binary compatibility and the continued availability of the 2.8.0.final version of the SDT will make this process less painful than it has been previously — you can either update to the 2.8.1.final version immediately, or continue with 2.8.0.final and update to 2.8.1.final when it’s convenient for your project, whilst still being able to take advantage of ongoing improvements in the Eclipse tooling.

This is the first time that this has been possible — enabling smoother version transitions for users of the Scala tooling was one of the primary goals of the Scala IDE for Eclipse becoming an independent project and it is very satisfying to see that this is working out in practice. One of the project’s continuing goals is to ensure that Eclipse users won’t again have to choose between sticking with a particular stable release of the main Scala toolchain versus benefiting from improvements in the Eclipse integration.

The version of the Scala tooling that is offered on the front page of scala-ide.org by default has been bumped up to 2.8.1.final, and you can continue to update and install for 2.8.0.final using the alternative build update sites available here.

(from the announcement)

Scala 2.8.1 Final Version Released

A new stable release of Scala is available for download!

Many thanks to all our contributors and testers.

You can find the new Scala 2.8.1 on our Download Page.

This new release addresses a large number of bugs, and introduces some additional improvements, noticeably in the Scaladoc tool. The new Scala 2.8.1 has been designed to be fully binary compatible with the previous version 2.8.0.

(From the announcement)