Thursday, February 23, 2012

Sample App Tour

In my last blog, I performed a very short DB migration from a local PostgreSQL installation to one running in the cloud. In this blog, I want to share the small "wine database" application that I used. All of the code is available in this zip file, including a pom.xml file for building through maven (if you want to build without maven, the only dependencies are the Java EE APIs and Vaadin -- see below). My target audience is developers who know how to set up JDBC connection pools and generate DB tables, but if there's interest I can follow up with a step-by-step guide to deploying this application.

Before getting into the application, here is the SQL used for creating the database tables and initial information (the file is also included in the zip above in the 'sql' directory). There are two simple tables, one for wines and one for wine classifications. The wine table holds a foreign key to entries in the classifications table.

The application is a small Java EE app using Vaadin for the web framework. Because the last post was more about the database than the application, it's not a full CRUD app: it's more CR-oriented in that you can save and view data only. Very little code is required to create this application: one POJO for each DB entity/table, a simple EJB service object between the UI and back end, three files for the whole UI, and a very short servlet class used to load the UI. Please see the source code for full comments, but here is the relevant part of the servlet class:
@WebServlet(urlPatterns = {"/app/*", "/VAADIN/*"})
public class UIServlet extends AbstractApplicationServlet {
    WineService service;
    protected Application getNewApplication(HttpServletRequest request)
        throws ServletException {
        return new MainUI(service);
    protected Class<? extends Application> getApplicationClass()
        throws ClassNotFoundException {
        return MainUI.class;

That's all that's needed to create the Vaadin application object and pass a reference to the EJB service to it. From there, the class creates a small user interface with a table and single button for adding more entries to the table. The button has a listener that pops up a child window containing the form for adding another entry:

To access the back-end data, I'm using two separate strategies. That may sound complicated, but it's actually due to laziness (a good trait in engineers when used properly!). The table is using Vaadin's SQL Container, which is very easy to set up. It connects to the database through SQL directly, and handles details like paging, optimistic locking, etc, automatically. The form that adds new wines is using JPA, which also means very little code to write since the EJB can persist an entity while handling transactions, locking, etc, with one line of code:

    public void store(Wine wine) {

The data source for the table, the SQLContainer, can use a database connection pool to perform its queries. This is as simple as using new J2EEConnectionPool("jdbc/WineDB") in the table class. Because this jndi name is used here and in persistence.xml, both database access methods use a single definition of the datasource, as shown here from the GlassFish administration console. Here is the resource definition:

...and here are the relevant details of the winedb-pool connection pool:

Thus, I can change the location of the database in only one place and the application will find it. I'm letting the database assign primary keys rather than letting JPA do it. Here is the SQL, for example, for creating the classification table and inserting some data:
create table classification (
  id               serial primary key,
  class_name       varchar(255) not null
insert into classification (class_name) values ('Cabernet');
insert into classification (class_name) values ('Merlot');

In my JPA entity, I use the following annotations to work with the primary key generation strategy:
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private int id;

This makes it easier to access the database through tools outside of the application itself, without worrying about details like a key generation table.

One last note about the application: every class in the app is serializable, which is required by Vaadin and which is a good idea in general for a web app (so the container can persist your session to some storage or to enable replication/failover). I didn't bother with generating serialVersionUIDs for the UI classes since they will only be serialized/deserialized by the container and not transferred around. I could have done the same with the entities, but for these I try to remember to generate the IDs just in case a future version of an application uses them as DTOs. In this case, it's just a matter of preference.

For a future blog, I hope to rewrite the app to run in Tomcat and deploy it to Amazon's Elastic Beanstalk using the JDBC URL property to connect it to the cloud database.

Monday, February 13, 2012

Migrating Your PostgreSQL Database to the Cloud

Now that EnterpriseDB has launched the Postgres Plus Cloud Database, it's easy to get a database running in the cloud. This blog covers the next step: migrating a PostgreSQL database that you already have running on traditional hardware to your new cloud database.

To provide a full example, this entry uses a simple web application written in Vaadin. I'm running it on a GlassFish 3.1.1 application server (supports Java EE 6), and the application talks to a PostgreSQL 9.1 database through a JDBC connection that's configured in the server. This means there's only one place I need to change my connection information once the data has been migrated.

The application itself is a very simple database for storing information about wine. I'll give a walkthrough of the application in a subsequent blog, followed by a version that runs on Tomcat that could be deployed to Amazon Elastic Beanstalk.

For better viewing, here is a direct link to the video embedded below.

After setting up the remote database in the cloud, the migration happens in three steps:
  1. Back up the existing database to a file.
  2. Restore the data into the new database.
  3. Point the application to the new database location (and restart if necessary).
For the screen cast, I'm using all command line tools. For more information on using the PostgreSQL tools from the command line, see this article from EnterpriseDB.

Note that the GlassFish administration can be performed from the command line as well. To see a list of the properties that are set, you can use the asadmin "get" command and grep for the information (if you don't already know the property names):

BobbyMac}> ./asadmin get "*" | grep wine | grep property

Similarly, you can use the asadmin "set" command to change these values. Then you can redeploy the application to pick up the new values.

Thursday, February 2, 2012

A Tour of the Cloud Database Console

This is a short screen cast giving a tour of the Postgres Plus Cloud Database console. From the console, you can easily create and manage database clusters through a web interface.

Here is a direct link to the video on YouTube.

For more information, please see the cloud database link above or the forum from EnterpriseDB.