Michael Ivey's Blog

Databases Archives

Quick and Easy Object Persistence: pBeans + Groovy Beans

Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it.
-- Larry Wall, Tom Christiansen, and Randal L. Schwartz, Programming Perl, 2nd Edition

I started my programming life in Perl, and I am a lazy programmer. I get frustrated when I have to write duplicate code, or put information in more than one place. I'll search the web for days, try sample applications in 10 different frameworks, and write hundreds of lines of test code to find a solution that saves me half an hour. Now that's lazy.

I've been looking at persistence layers and frameworks lately. I don't like having SQL in my objects, partially because it makes things more brittle, and partially because I don't like writing SQL anywhere. I just want to write classes and instantiate objects, manipulate them for a while, and then have them stick around. I don't really care about the database itself. (In fact, most of the time I don't need a database, that's just a simple way to store stuff.)

I'm sure that somewhere there is a good list and comparison of available persistence layers, so I won't try to duplicate that here. What I will say is that almost everything I looked at required at least one of the following, and usually more than one:

• Extending a framework class
• Implementing a complex interface
• Writing XML mapping files
• Writing mapping classes
• Generating a database schema at compile time
• Code generation

Prevayler-style in-memory storage is kind of cool, but it also places restrictions on how you structure your client classes. I don't want restrictions, I don't want extra work, and I don't want duplicated code or information. How do I do it?

pBeans is one way. It really is as simple as I was looking for. Make some Beans, tag them with implements Persistent, make a store, and then put objects in the store and take them out. No SQL (one exception; read on), no XML, no mapping files. Free as in speech. Currently works with MySQL, Postgres, and SQL Server, and should be fairly easy to get working on other databases.

Here's how it works:

1. Create an instance of net.sourceforge.pbeans.data.GenericDataSource
2. Configure that DataSource with a JDBC driver and a database URL
3. Use that DataSource to get an instance of net.sourceforge.pbeans.Store
4. Create some JavaBeans
5. Call insert(), save(), delete(), and select() on the Store with those beans
6. Laugh at how easy it was to get your objects stored in the database

Well, mostly happy. JavaBeans make persistence easy, but violate another of my lazy principles: duplication. I can't stand writing getters and setters for every field. Java is already too verbose for my tastes, coming from a loose typing background. 2 copy-paste methods for every field is too much. Enter Groovy Beans.

Groovy is quite possibly the best thing I've encountered in the Java world, period. It makes writing for the Java platform enjoyable for me, and it really helps my wrists not hurt so much. Here's an example:

public class User {

    private Integer id;
    private String name;
    private String favoriteColor;

    public Integer getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public String getFavoriteColor() {
        return favoriteColor;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public void setName(String name) {
        this.name = name;
    }

    public void setFavoriteColor(String favoriteColor) {
        this.favoriteColor = favoriteColor;
    }

}

class User {
   Integer id
   String name
   String favoriteColor
}

import net.sourceforge.pbeans.data.*
import net.sourceforge.pbeans.*

dataSource = new GenericDataSource()
dataSource.setDriverClassName("com.mysql.jdbc.Driver")
dataSource.setUrl("jdbc:mysql://localhost/test?user=test&password=test")

store = new Store(dataSource)

class User implements Persistent {
    Integer id
    String name
    Integer age
    String hometown
}

joe = new User(name:"Joe User", age:43, hometown:"Bay Minette, AL")
store.insert(joe)
newjoe = store.selectSingle(User.class, "name", "Joe User")
assert newjoe.hometown == "Bay Minette, AL"

SQLite ... quick and dirty SQL server

I was working on a Perl project this weekend. (You know, Perl. "It's like Java, only it lets you deliver on time and under budget." *) I was doing a bunch of awfulness with SQL-over-CSV files, but I really needed a database. I didn't want to go through the hassle of installing one, even though, on Debian, it's just apt-get install postgresql-client postgresql-server. Then I'd have to create database users, muck with security, and then my evening ends up diverted to system admin tasks. I just want a simple SQL engine that's easy to deploy.

You'd think I would have found it sooner. If I didn't dislike PHP so much, I might have found it there. As it was, I only stumbled across it because a module I was using wouldn't work with Postgres's sequences, and as I was wading through the code, I saw it mentioned: SQLite.

So what is it? "SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. ... SQLite is not a client library used to connect to a big database server. SQLite is the server. The SQLite library reads and writes directly to and from the database files on disk."

It's beautiful. It's simple. It's embeddable. There's a Java binding wih JDBC. And it's "two times faster than PostgreSQL and MySQL for many common operations."

It's not for everyone. The security is whatever the OS provides for files. It's not fully SQL92 complete (here's the list of what it doesn't do), even compared to MySQL. The locking is file-based and operates on the whole database.

Oh yeah, it's typeless. Want to shove some text in an int column? Go ahead. It's OK.

For simple apps that need to do a little SQL, but don't need all the bells and whistles, it's great. And for developers running local test cases all over, without wiping out production or semi-production databases, it could be a lifesaver.

This work is licensed under a Creative Commons License.