smalltalk programming for the web

World Cup 2018 with Glorp

10 June 2018

I last wrote about football.db in a Jul 2014 blog post. Four years have gone by, and the World Cup is here again. This time around, I've started building a Glorp descriptor system for the World Cup data.

football.db's data is described in YAML files which are assembled into SQLite databases using tools written in Ruby. From the constructed 2014 and 2018 World Cup databases, I've created SQL dumps and placed them in the repo. To get an SQLite database from the 2018 SQL dump file:

% sqlite3 wc2018.db < wc2018.sql

In its current state, footballdb-Glorp allows querying the initial World Cup first round group membership.

| login sess |
login := Login new
  database: UDBCSQLite3Platform new;
  host: '';
  port: '';
  username: '';
  password: '';
  databaseName: '/tmp/wc2018.db';
sess := OFDescriptor sessionForLogin: login.
sess login.
[   Transcript clear.	
    (sess read: OFTournamentTeam) do: [ :ea |
      Transcript show: ea group title , ' - ', ea team title; cr ]
] ensure: [ sess logout ].

This Glorp descriptor may not be completed in time for this World Cup which is starting in a few days, but will be in time for the next one for sure! :-) Load it thusly:

Metacello new 
  repository: 'github://PierceNg/footballdb-Glorp:master/repo';
  baseline: 'OpenFootball';

SQLite Boolean

20 May 2018

From its documentation, SQLite does not have a separate Boolean storage class. Instead, Boolean values are stored as integers 0 (false) and 1 (true).

I've added Boolean handling to UDBC-SQLite. When writing to an SQLite database from Pharo, true is written as integer 1 and false as integer 0. SQLite uses dynamic typing, and any column in an SQLite database, except an INTEGER PRIMARY KEY column, may be used to store a value of any type, irrespective of the column's type declaration. As such, when writing Boolean values to a database, UDBC-SQLite does not check the database's type declaration.

When reading an SQLite database, UDBC-SQLite does check a column's type declaration: If a column is Boolean, UDBC-SQLite reads 1 as true, 0 as false, NULL as nil, and any other integer values raises an exception. I've encountered real world data where the string "t" means true and "f" means false for a Boolean column, so UDBC-SQLite handles these cases too.

Glorp has been similarly updated. Loading GlorpSQLite, from my development fork for now, installs both UDBC-SQLite and Glorp:

Metacello new
  repository: 'github://PierceNg/glorp-sqlite3';
  baseline: 'GlorpSQLite';

All Glorp unit tests should pass. Tested on Linux using fresh 32- and 64-bit 60540 images.


18 March 2018

I've just added RIPEMD160 to the EVP interface in OpenSSL-Pharo. This post serves as a HOWTO.

OpenSSL's C interface defines RIPEMD160 thusly:

const EVP_MD *EVP_ripemd160(void);

Create LcLibCrypto>>apiEvpRIPEMD160 for it:

  ^ self ffiCall: #(EVP_MD* EVP_ripemd160 ())
    module: self library

Next, create LcEvpRIPEMD160 as a subclass of LcEvpMessageDigest:

LcEvpMessageDigest subclass: #LcEvpRIPEMD160
  instanceVariableNames: ''
  classVariableNames: ''
  package: 'OpenSSL-EVP'

  super initialize.
  handle := LcLibCrypto current apiEvpRIPEMD160.
  self errorIfNull: handle

Add class-side accessors:

LcEvpRIPEMD160 class>>blocksize
  ^ 64

LcEvpRIPEMD160 class>>hashsize
  ^ 20

And that's it! Using the test vectors from the RIPEMD160 home page and RFC 2286, the unit tests verify that we can now use RIPEMD160 for hashing and HMAC from within Pharo:

  | msg result |

  msg := ''.
  result := ByteArray readHexFrom: '9c1185a5c5e9fc54612808977ee8f548b2258d31' readStream.
  self assert: (md hashMessage: msg) equals: result

  | msg result expectedResult |

  msg := 'Hi There'.
  key := ByteArray readHexFrom: '0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b' readStream.
  expectedResult := ByteArray readHexFrom: '24cb4bd67d20fc1a5d2ed7732dcc39377f0a5668' readStream.
  result := (HMAC on: LcEvpRIPEMD160)
    key: key;
    digestMessage: msg asByteArray.
  self assert: result equals: expectedResult

SQLite Loadable Extensions

4 March 2018

SQLite has the ability to load extensions at run-time. I've now implemented this functionality in UDBC-SQLite.

An SQLite extension is built as a .so/dylib/dll shared library file. Let's use SQLite's rot13 extension as our example. The source file rot13.c is located in the SQLite source code's ext/misc directory. To build the rot13 extension, also download the amalgamation. Unzip the amalgamation and copy rot13.c into its directory. Build the extension:

% gcc -fPIC -shared -o -I. rot13.c

Verify that the extension works:

% sqlite3
SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> select rot13('qwerty');
Error: no such function: rot13
sqlite> .load "./"
sqlite> select rot13('qwerty');
sqlite> select rot13('djregl');

For use with Pharo, copy into the Pharo VM directory where all the other .so files are.

Next steps are done in Pharo. For the purpose of this blog post, I downloaded a fresh Pharo 60536 64-bit image. Start the image and install GlorpSQLite from the Catalog browser, which installs the latest UDBC-SQLite. (This also installs Glorp, of course. If you run Glorp's unit tests from Test Runner you should get all 890 tests passed.)

In a playground, run this snippet and Transcript should show, first, the text "no such function: rot13" and then the rot13 outputs.

| db rs r1 r2 |
Transcript clear.
db := UDBCSQLite3Connection openOn: ':memory:'.
[   [ db execute: 'select rot13(''qwerty'')' ]
      on: UDBCSQLite3Error
      do: [ ex: | Transcript show: ex messageText; cr ].
    db enableExtensions;          "<== New stuff."
      loadExtension: ''.  "<== New stuff."
    rs := db execute: 'select rot13(''qwerty'') as r1'.
    r1 := rs next at: 'r1'.
    Transcript show: r1; cr. 
    rs := db execute: 'select rot13(?) as r2' with: (Array with: r1).
    r2 := rs next at: 'r2'.
    Transcript show: r2; cr.
] ensure: [ db close ]

Note the messages #enableExtensions and #loadExtension:. For security reasons, extension loading is disabled by default.

Tested on Linux latest Pharo 64-bit 60536.