Thursday, August 31, 2006

Less Than, Greater Than and Everything in Between

Some new stuff has gone into Sql4o:
  • supports all the comparison operations for the queries: <, >, <=, >=, =, <>, != .
  • supports Integers, Longs and Doubles as well as Strings.
  • and lastly, you can now build more complex where statements and they get correctly converted into SODA!
    • eg: from com.spaceprogram.db4o.Contact c where (age = 10 or age = 20) and income >= 50000.02
The latest code in SVN has it all, and of course this also means that you do do all this fun stuff in the latest ObjectManager source.

Next up... Aggregation.

Friday, August 25, 2006

Db4o on the Desktop

I've been taking the reigns on the new db4o ObjectManager 2.0 and of course I love to eat our own dog food (this ain't no kibbles and bits), so db4o is used for everything that needs persisting. This includes all the user settings, preferences, previous connections, query history, even previous window locations, and any other state I can get my hands on. I'm really trying to make it remember your previous sessions so you don't have to repeat anything the next time you start it up. And this turns out to be a LOT easier than you'd expect.

How It Works

There is a single HashMap in a Preferences object with a couple main methods; Preferences.get(String key) to retrieve any Object and Preferences.set(String key, Object value) to store anything that's changed. When set(key, object) is called, it will store and commit to a db4o database. The Preferences object is read in from the db4o database at startup and it is used to setup the application. If certain keys are not found in the Preferences HashMap, the default values are used.

Now every time the the app is restarted, the previous state can be restored with a simple db4o query asking for the Preferences object.

This is perhaps the easiest and most reliable way to store state across sessions for any desktop application. Plus you get the power of having a full-fledged object database at your disposable for storing all the other data in your application.

Why is this better than java.util.prefs ?

Because you can store objects, and it's much easier to use. Consider these comparisons:
  • Store and retrieve a database connection
    • With java.util.prefs, you'd have to store the connection url, username, and password in three different keys or as some string that you'd later have to parse, then probably put them in a DatabaseConnectionInfo object to use in your program.
    • With db4o prefs, you just store the DatabaseConnectionInfo object, then retrieve the full object again.
  • Storing frame size and location
    • With java.util.prefs, you'd store "width", "height", "top", and "left" values, then you'd have to get each of those and put them into a Dimension and Point object.
    • With db4o prefs, you store the Dimension and Point directly off the component and retrieve those directly back to set on the component.
      • eg: on componentResized(ComponentEvent e){
        Preferences.set("frameSize", e.getComponent().getSize());
      • then on startup: frame.setSize(Preferences.get("frameSize"));
So simple, yet saves so much time.

Wednesday, August 16, 2006

SQL For Objects - Sql4o

I’ve started an SQL for Objects project to enable string based querying support for db4o. This means you will be able to write queries like:

select * from com.abc.Contact c where c.name = 'leroy'

The project page is up here:

http://developer.db4o.com/ProjectSpaces/view.aspx/SQL_Support

The subversion repository with the code is up here:

http://code.google.com/p/db4o-sql/

I’ll release a jar file soon.

db4o Performance

When I tell people about db4o, I will always mention the following two things:

  1. It cuts your development time significantly (25% or more I would say). No more creating database schemas and making mapping files to map from your objects to your tables.
  2. It’s FAST! As in faster than that relational database you’re using right now.

Now a note on performance, take a look at these benchmark results. They compare a variety of common setups including Hibernate with MySQL and HSQLDB. db4o is clearly faster in most cases. And these benchmarks were done with db4o 5.2. db4o 5.5 is currently the latest and greatest and is generally substantially faster than 5.2. It will be interesting to see the Pole Position results with 5.5.

After seeing these benchmark results and knowing that db4o can save you a boatload of time (it’s also so pleasant to use), why would you not choose it?

Sunday, August 13, 2006

For All Things db4o... Unofficial

This blog will keep you abreast on all things unofficial for db4o.