C[omp]ute

From: andrew cooke <andrew@...>

Date: Wed, 7 Oct 2009 23:28:18 -0400

Bringing together two different language paradigms doesn't seem to be
easy.  For example, merging OO and functional programming seems to
have taken quite some time.  I am not sure where the problem lies -
perhaps it takes time to develop appropriately balanced languages, or
perhaps people just need time to adjust.

Another example is how best to access relational databases from OO
languages.  The most popular approach seems to have been to emphasise
the objects as much as possible, and then slowly introduce SQL-like
(more declarative) features.  That is how I would (roughly)
characterise the approach taken by, say, Hibernate.

But just as functional ideas are starting to spread into the OO
mainstream, so there are few signs that a more declarative, SQL-like
approach may be useful for some problems.  Perhaps the best example is
LINQ which I have not had the chance to use.

Two other libraries that take a vaguely similar approach (although,
been libraries, they are not sa deeply integrated as I think LINQ is)
are SQLAlchemy for Python and Empire DB for Java.  Both these place
the primary emphasis on constructing SQL queries; building objects
from the results comes second.

Personally, as someone who actually likes using SQL, I find this
approach very interesting.

Recently I started a new, small project, to learn Scala: I decided to
write a playlist generator that would take my MP3 collection and use
metadata to construct graphs of connected tracks.  Given the above I
also decided to try using Eclipse DB.

What follows are some examples from my initial code.  I am still
working on constructing the database, given a set of MP3 files, and I
am sure my code will evolve significantly before I finish.  But what I
have is already interesting and I thought it would be useful to share
it.

Empire DB is at http://incubator.apache.org/empire-db/

The changeset for the code that I have as I write this is at
http://code.google.com/p/uykfd/source/detail?r=a834c704643dc48642bb71e74aa7c4c967ea1da9


I thought I would focus on two areas of the code.  First, the database
definition.  This is used (1) to define the database (Empire DB
creates SQL that builds the schema) and (2) to define instances of
Java classes that will support the construction of type safe queries.

The database definition is here -
http://code.google.com/p/uykfd/source/browse/src/main/scala/org/acooke/uykfd/db/Schema.scala?spec=svna834c704643dc48642bb71e74aa7c4c967ea1da9&r=a834c704643dc48642bb71e74aa7c4c967ea1da9#21
- and I will also cut+paste some examples below.

Here, for example, is a class that describes a table with two columns
- an auto-increment key and some varchar text:

  class IdValue(name: String)
      extends DBTable(name, this) {
    val ID = addColumn("ID", DataType.AUTOINC,
                       0, true, name + "_SEQ")
    val VALUE = addColumn("VALUE", DataType.TEXT,
                          MAX_VARCHAR, true)
    setPrimaryKey(ID)
  }

This can be then instantiated -

  object CANONICALS extends IdValue("CANONICALS")

- to create a table, called CANONICALS, that has two columns (ID and
VALUE), with the types as above.  Later Scala code can refer to those
columns as CANONICALS.ID and CANONICALS.VALUE

Note that Scala's object/class approach makes this code particularly
compact and transparent (at least if you know a little Scala).  With
both Empire DB and SQLAlchemy I have been impressed with how easy it
is to define a schema, including basic foreign key constraints, in a
engine-neutral manner (I am using HSQL, but the same code would work
with, say, Oracle or MySQL).


The second area I wanted to show was the code I use to generate
entries in the database.  This code is *not* as transparent as the
schema.  That is largely because I am writing quite generic code that
is reused for a variety of tables.  I hope I can improve this work.

However, some of the details are still worth showing.  For example,
look at the routines used to extract data from the database -
http://code.google.com/p/uykfd/source/browse/src/main/scala/org/acooke/uykfd/db/Schema.scala?spec=svna834c704643dc48642bb71e74aa7c4c967ea1da9&r=a834c704643dc48642bb71e74aa7c4c967ea1da9#102

These are for all tables that follow the ID/VALUE layout I described
above and the first method, fromValue, constructs a SQL query to fine
the value:

    val cmd = Schema.createCommand
    cmd.select(row.table.getColumns)
    cmd.where(row.table.VALUE.is(value))

Notice how there are no strings used for table names in that snippet.
Everything is defined in terms of the schema described above.

OK, that will have to do for now - I need to get some sleep.

Andrew