| Andrew Cooke | Contents | Latest | RSS | Twitter | Previous | Next

C[omp]ute

Welcome to my blog, which was once a mailing list of the same name and is still generated by mail. Please reply via the "comment" links.

Always interested in offers/projects/new ideas. Eclectic experience in fields like: numerical computing; Python web; Java enterprise; functional languages; GPGPU; SQL databases; etc. Based in Santiago, Chile; telecommute worldwide. CV; email.

Personal Projects

Lepl parser for Python.

Colorless Green.

Photography around Santiago.

SVG experiment.

Professional Portfolio

Calibration of seismometers.

Data access via web services.

Cache rewrite.

Extending OpenSSH.

C-ORM: docs, API.

Last 100 entries

Why Information Grows; The Blindness Of The Chilean Elite; Some Victoriagate Links; This Is Why I Left StackOverflow; New TLS Implementation; Maths for Physicists; How I Am 8; 1000 Word Philosophy; Cyberpunk Reading List; Detailed Discussion of Message Dispatch in ParserCombinator Library for Julia; FizzBuzz in Julia w Dependent Types; kokko - Design Shop in Osaka; Summary of Greece, Currently; LLVM and GPUs; See Also; Schoolgirl Groyps (Maths); Japanese Lit; Another Example - Modular Arithmetic; Music from United; Python 2 and 3 compatible alternative.; Read Agatha Christie for the Plot; A Constructive Look at TempleOS; Music Thread w Many Recommendations; Fixed Version; A Useful Julia Macro To Define Equality And Hash; k3b cdrom access, OpenSuse 13.1; Week 2; From outside, the UK looks less than stellar; Huge Fonts in VirtualBox; Keen - Complex Emergencies; The Fallen of World War II; Some Spanish Fiction; Calling C From Fortran 95; Bjork DJ Set; Z3 Example With Python; Week 1; Useful Guide To Starting With IJulia; UK Election + Media; Review: Reinventing Organizations; Inline Assembly With Julia / LLVM; Against the definition of types; Dumb Crypto Paper; The Search For Quasi-Periodicity...; Is There An Alternative To Processing?; CARDIAC (CARDboard Illustrative Aid to Computation); The Bolivian Case Against Chile At The Hague; Clear, Cogent Economic Arguments For Immigration; A Program To Say If I Am Working; Decent Cards For Ill People; New Photo; Luksic And Barrick Gold; President Bachelet's Speech; President Bachelet's Speech; Baltimore Primer; Baltimore Primer; libxml2 Parsing Stream; libxml2 Parsing Stream; configure.ac Recipe For Library Path; configure.ac Recipe For Library Path; The Davalos Affair For Idiots; Not The Onion: Google Fireside Chat w Kissinger; Not The Onion: Google Fireside Chat w Kissinger; Bicycle Wheels, Inertia, and Energy; Bicycle Wheels, Inertia, and Energy; Another Tax Fraud; Google's Borg; Google's Borg; A Verion That Redirects To Local HTTP Server; Spanish Accents For Idiots; Spanish Accents For Idiots; Aluminium Cans; Aluminium Cans; Advice on Spray Painting; Advice on Spray Painting; Female View of Online Chat From a Male; Female View of Online Chat From a Male; UX Reading List; UX Reading List; S4 Subgroups - Geometric Interpretation; S4 Subgroups - Geometric Interpretation; Fucking Email; Fucking Email; The SQM Affair For Idiots; The SQM Affair For Idiots; Using Kolmogorov Complexity; Using Kolmogorov Complexity; Oblique Strategies in bash; Oblique Strategies in bash; Curses Tools; Curses Tools; Markov Chain Monte Carlo Without all the Bullshit; Markov Chain Monte Carlo Without all the Bullshit; Email Para Matias Godoy Mercado; The Penta Affair For Idiots; The Penta Affair For Idiots; Example Code To Create numpy Array in C; Example Code To Create numpy Array in C; Good Article on Bias in Graphic Design (NYTimes); Good Article on Bias in Graphic Design (NYTimes); Do You Backup githb?; Do You Backup github?

© 2006-2015 Andrew Cooke (site) / post authors (content).

Using Scala with Empire DB

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

Outer Join and Sub-Select Example for Empire DB and Scala

From: andrew cooke <andrew@...>

Date: Thu, 8 Oct 2009 15:04:09 -0400

Here's a nice example where I am clearing out orphaned values (I don't
want to cascade on deletion for various reasons).

  def clean(cnxn: Connection) {
    val subCmd = Schema.createCommand
    subCmd.select(Schema.ARTIST_TAGS.ID)
    subCmd.join(Schema.TRACKS.ARTIST_TAG,
                       Schema.ARTIST_TAGS.ID, DBJoinType.RIGHT)
    subCmd.where(Schema.TRACKS.ID.is(null))
    val orphanArtists = new DBQuery(subCmd)
    val cmd = Schema.createCommand
    cmd.where(Schema.ARTIST_TAGS.ID.in(orphanArtists))
    Schema.executeSQL(cmd.getDelete(Schema.ARTIST_TAGS), cnxn)
  }

The right join constructs a table with all the artists, then I select
those fr which there is no corresponding track (null ID).  That is
used as the sub-select for deletion.

Andrew

And If You Still Don't Get It

From: andrew cooke <andrew@...>

Date: Thu, 8 Oct 2009 15:16:48 -0400

Because it's code, it's easy to reuse:

  def clean(cnxn: Connection) {
    def cleanOrphans(tag: DBColumnExpr, table: Schema.Id) {
      val subCmd = Schema.createCommand
      subCmd.select(table.ID)
      subCmd.join(tag, table.ID, DBJoinType.RIGHT)
      subCmd.where(Schema.TRACKS.ID.is(null))
      val orphans = new DBQuery(subCmd)
      val cmd = Schema.createCommand
      cmd.where(table.ID.in(orphans))
      Schema.executeSQL(cmd.getDelete(table), cnxn)
    }
    cleanOrphans(Schema.TRACKS.ARTIST_TAG, Schema.ARTIST_TAGS)
    cleanOrphans(Schema.TRACKS.ALBUM_TAG, Schema.ALBUM_TAGS)
    cleanOrphans(Schema.TRACKS.SONG_TITLE_TAG, Schema.SONG_TITLE_TAGS)
  }

Andrew

Comment on this post