Data Modeling with DODS

Part of the Enhydra server, DODS tries to bridge object andrelational databases.
Pulling It All Together

Our class is where most of the magic happens. It creates instances of both Welcome.html and of our database objects, retrieves the query results and then inserts those results into the HTML file.

After you modify, as shown in Listing 3 [available at], run a make from the top-level directory for this project. Enhydra will compile your Java classes, double-check that everything is where it should be and get your application ready to run.

Notice in Listing 3 that we had to modify the definition of the “run” method such that it returns two new exceptions: NonUniqueQueryException and DataObjectException. These are generated by the various data objects that we've created, and since we aren't going to catch these exceptions, we must indicate to the caller that we may raise them.

Listing 3 uses the Enhydra QueryBuilder to create an SQL query using methods created by DODS. We first create an instance of BlogEntriesQuery, one of the automatically created classes:

BlogEntriesQuery blogq = new BlogEntriesQuery();

We want to retrieve all rows until now, in reverse order by entryDate:

blogq.setQueryEntrydate("NOW()", QueryBuilder.LESS_THAN);
There are also methods for adding WHERE clauses to our SQL query, letting us create arbitrarily complex SQL queries.

Finally, we retrieve an array of matching rows, each of which is represented by a BlogEntriesDO object:

BlogEntriesDO[] blogEntries = blogq.getDOArray();

We're only going to display the most recent one, so we will simply get the first element of our array. We use the method in our “welcome” object, created by XMLC, to insert the appropriate text in our document:

Once we have modified, we create the application by running make from our top-level project directory. If you see any errors in your Java program, you can correct them and rerun make as often as you want.

Theoretically, you could now run the application by changing into the output subdirectory and running ./start. But our application will fail if we do this, since it doesn't yet know where to look for the PostgreSQL .jar file. In addition, it's useful to get full debugging output from Enhydra (or any application) when we're first using it, so that we can identify and fix problems more quickly.

We must modify three files in order to get things to work. First, we need to modify $ENHYDRA/bin/multiserver by adding a reference to the PostgreSQL JDBC driver's .jar file. To do this, we simply modify the multiserver (which is a shell script that invokes a Java program), changing the lines under the comment “build up classpath” to the following:

# Where is the PostgreSQL JDBC .jar file?
if [ "X${CLASSPATH}" = "X" ] ; then

Next, we modify blog.conf. Every Enhydra project has a configuration file that tells the system which database to use, as well as a number of other properties. In my particular case, the configuration file is blog/output/conf/blog.conf and consists of a lot of name-value pairs for my application.

We must modify several parts of the “Database manager” section in order to point to our programs. You can see the full section, as it needs to be, in Listing 4 [available at].

Finally, we modify servlet.conf. Although this doesn't need to be modified, I find it useful to turn on DEBUG mode by modifying the following two definitions:


The most important thing to realize about blog.conf and servlet.conf is that they are regenerated every time you do a top-level make. So once you have modified them in this way, never do a top-level make again. You will be quite sorry (as I have been) if you do so. Rather, do a make from within the presentation directory.

Once you have modified the configuration in this way, you can go into ~/enhydraApps/blog/output and run ./start. You will see the server start up, plus a fair amount of debugging information if you activated DEBUG in servlet.conf and logging in blog.conf.

You can check out your creation by pointing your web browser to point 9000, the default port for Enhydra applications: http://localhost:9000/. If all is well, you should see the output from our weblog in your web browser.


One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix