EoD SQL 2.1-Beta Released

EoD SQL 2.1-Beta has been released, you can go download it from the Documents & Files section of the homepage. The 2.1 release is about improving speed and usability over the 2.0 release. Some of the new features included are:

  • Specific Collection implementations (including those not in the standard Java API’s) can now be returned:
    @Select("SELECT * FROM users WHERE group = ?{1.id}")
     ArrayList<User> selectUserGroup(Group group);
  • Select methods can now populate existing objects:
    @Select(sql="SELECT * FROM user_meta_info WHERE user_id = ?{1.id}",into=1)
    void selectMetaInfo(User user);
  • Faster construction of query implementations
  • Better error reporting
  • Several small bug fixes

This is of course a beta release, so there may be bugs. That said the code is pretty well unit tested and should be relatively stable. One new feature not in the release (but on the way) is batch updates. Stay tuned for more information!

Using an Aladdin eToken with Java keytool

The Aladdin eToken is a great little security device when you have sensitive private key information. They are a great USB solution in that they support all major operating-systems with a PKCS#11 driver. This means they also integrate with Java on all major platforms (through the SunPKCS11 Security Provider).

The one problem we have come across  with the device is trying to create keys on it using the standard Java keytool application. There are two errors you’ll almost certainly face, both in the form of a sun.security.pkcs11.wrapper.PKCS11Exception.

Error 1: CKR_ATTRIBUTE_TYPE_INVALID

This error (we found) pops up when you don’t specify the key algorithm on the command line. You need to specify “-keyalg RSA” to ensure that an RSA key (instead of the default DSA) is generated for the eToken.

Error 2: CKR_TEMPLATE_INCONSISTENT

This one is a little more nasty.  It’s not well documented, but effectively the keytool doesn’t generate signatures that the eToken’s PKCS#11 implementation likes (we couldn’t find any tool other than the eToken software that did). Under Windows you need a registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Aladdin\eToken\MIDDLEWARE\GENERAL

The key is a DWORD attribute: “TolerantX509Attributes” with a value of “1”. But what about Mac and Linux. You’ll need to look for the eToken config file: /etc/eToken.conf, then under the “[GENERAL]” section of the file add the line:

TolerantX509Attributes=1

This will allow keytool (and other PKCS#11 tools) to generate and store keypairs on your USB eToken.

A Command Line Example

keytool -v -genkeypair -keyalg RSA -alias myKey -keystore NONE -storetype PKCS11 -providerClass sun.security.pkcs11.SunPKCS11 -providerArg /home/me/pkcs11.conf

EoD SQL Applied – Part 5 / 5 (GWT Applications)

The Dreaded “Not Serializable” Problem

GWT turns all of your Java code into JavaScript, but it also obfuscates everything. With this in mind, it makes serialization a bit more complex than usual. GWT generates a serializer and deserializer for each class that could be transported across the wire to an RPC service. The difficulty comes in knowing which types had code generated, and which didn’t. GWT solves this problem for itself with the Serialization Policy file, where the compiler lists all of the classes that the client code will know how to deserialize.

This however leads to another problem: what happens when something unexpected gets in the way. Hibernate is the most used, and thus most complained about when it comes to Serialization problems. Hibernate turns any Collection object into a special “lazy” implementation that will only load your data when you ask for it. All very fine and well for a server bound application, but a GWT application needs all that data up front for serialization. When GWT comes to sending that List<Message> to the client, it chokes. It knows how to serialize an ArrayList, and LinkedList (since you worked with them on the client side), but a Hibernate List or PersistentCollection is a totally unknown type, so it’s not in the Serialization Policy, so the server side throws an Exception at you.

So how does EoD SQL help with these problems? Read on to find out! 😉 Read the rest of this entry »

EoD SQL Applied – Part 4 / 5 (JavaScript)

JavaScript vs. Web Applications

So far in this series we’ve discussed using DataSets for Swing applications and DataIterators for web-applications. Why would I now bring in JavaScript as something outside of “web-application”? JavaScript applications have very different requirements to a normal web-application. Where a normal web-application has little ability to do things like preload data (like the next page), a JavaScript application may (for example) download the entire data-set and then display it in pages. This next section is about binding to JSON for JavaScript applications.

First thing to remember here is that an EoD SQL DataSet is a List and thus compatible with the Collections API. For this example we’re going to be working with the outstanding GSON API from our friends at Google. Our objective here is to minimize the amount of time spent between the Database and pushing the data to the client. Because GSON doesn’t appear to support Iterable object out-of-the-box, we’re going to start off using a DataSet.
Read the rest of this entry »

EoD SQL Applied – Part 3 / 5 (JSP / Servlets)

Static Data Display

In a Swing application with a direct connection to a database, it makes sense to leave the database to do much of the heavy lifting. The Swing client can keep a minimum amount of data in memory, while holding a scrollable Result Set open on the database (fetching more of the data as required). In a web application on the other hand, things are a little more complex. For one thing, your database isn’t exposed to the any part of the network; for another: your clients have no ability to keep Result Sets open; and finally: you generally are working with much higher loads than a Swing application.

EoD SQL has many different approaches to loading data from the database. We’ve already looked at DataSet objects, which remain connected to the database and work well with scrollable, cursor backed, Result Sets. DataSets are (in a way) a leftover from the origional EoD API from Java6-beta (where they were the only way to fetch objects from the database). In this post we’ll take a look at an EoD SQL idea: DataIterators.

Read the rest of this entry »

EoD SQL Applied – Part 2 / 5 (Swing Applications)

Swing Applications

Introduction

We start off the series with Swing Applications. Why? Although probably the application type least likely to be using EoD SQL right now, they nevertheless make use of the most commonly demonstrated EoD SQL data-structure: the DataSet. Swing Applications often have direct access to their database. They can therefore make much better use of long-lived database connections and cursor based ResultSets than web-applications can. So we open with a more detailed than-usual discussion of the DataSet interface and it’s implementations.

The DataSet is the original return type of the EoD API from Java 6 – beta. It’s a relatively thin wrapper on top of a scrollable ResultSet, and it performs best when your database that supports cursors, and your client that will be looking at large volumes of data over a longer periods of time. You’ll notice that this fits well with an intranet Swing client that has a direct connection to it’s database.

Read the rest of this entry »

Eod SQL Applied – Part 1/5 (Introduction)

Introduction

This is the first part of a series of posts, dedicated to how best to apply EoD SQL in different types of applications. Each post in this series will cover a specific type of application, and the different parts of EoD SQL that generally work best within those applications. The articles may dive fairly deep into the workings of the API, but at the end you’ll have a much better idea of where things fit in, and how they fit together.

EoD SQL well understands that (a) people like to do things differently and (b) one solution is not right for everything. While under the hood: any one part of EoD SQL works much the same way as any other part, as you climb the structural ladder, things begin to behave very differently. These behaviors have a massive performance and memory impact on your application and how you will be treating the underlying database drivers.

What we’ll be covering

  1. Swing Applications
  2. JSP / Servlets and “Related Technologies”
  3. JavaScript / JSON Applications
  4. GWT Applications

Although you could go with the “one size fits all” route (and EoD SQL would still perform wonderfully), the objective of these posts is to expose you to the different flavors of EoD SQL data structures and get you thinking about how you can mix and match them in your application to produce different results.