On Sun, 16 Feb 2003, Hannes Hirzel wrote:

> P.S. There are already some OO and non OO database efforts for Squeak
> see http://minnow.cc.gatech.edu/squeak/512 - Databases and Persistence

> Did somebody do an evaluation of the concepts / quality of these
> implementations?
> If yes, please post remarks there.

---
Object Databases:

> - File Dictionary

Extremely simple.  Allows a large (larger than memory) file to be treated
as a Dictionary by keeping an in-memory index.  Uses native Squeak
serialization (ReferenceStream, I think).  No
transactions/concurrency/etc.

> - MinneStore

Has been around for along time and seen a fair bit of use.  Feels somewhat
like using a relational DB - you have to declare type and relationship
info for your model.  In return, you get automatic indexing and query
facilities. Supports transactions.  Unclear what the state of concurrent
access is.  Don't know if it has GC.

> - Kats

Provides transactional semantics for in memory smalltalk objects.  Uses
a modified compiler to trap inst var reads/writes so that the same
instance can look different to different processes.  No persistence (but
watch out for Stephen's Chango, which should integrate Kats with a
transparent persistence layer using a modified VM).

> - GOODS

GOODS is a public domain distributed OODB written in C++.  This is a not
quite finished client for it - the protocol and serialization code is
stable, but the transactional level stuff needs a fair bit of work.  All
GC, crash recovery, concurrency, locking, schema evolution, etc is handled
nicely by the C++ server.  Transparent storage of any object (but can
provide more efficient storage with optional type info).

(If anyone has a strong interest in using this, I'd be happy to finish the
client - particularly if there's money involved ;).

> - Magma

Pure Squeak client/server OODB.  Somewhat immature (no class schema
evolution, no transaction logging) and not yet tested in the Real World,
but very promising.  Allows transparent, transactional storage of any
Squeak objects.

----
Relational Databases:

> - MySQL

Port of Josh Miller's socket-level VW MySQL driver.  Stable enough for
production work (at least with Colin Putney's patches, not sure if these
have been merged yet).  Maintains type information.

> - PostgreSQL

Socket-level Postgres driver.  Seems stable in recent releases.  Doesn't
yet maintain type info (all columns are retured as strings).

> - ODBC

Solid FFI interface to ODBC.  Works on Linux (with unixodbc), Windows, and
Mac OS X (with some effort - bug Colin for details).  Maintains type info,
and I've tried it successfully with drivers for MySQL, Postgresql, and
SQLite.

> - SQLite

An FFI interface to the SQLite library (small, in-process, fast relational
DB).  Less overhead (particularly configuration overhead) than going
through ODBC.  Simple and stable.

---
Object Relational Mapping:

> - Glorp

Object/Relational mapping framework, based on TOPLink.  Maps rows into
objects, to-one relationships into references, to-many relationships into
collections.  Currently only works with PostgreSQL.  Not in production use
AFAIK, but has extensive tests and is probably stable.

> - Tantalus

Another O/R mapping layer.  Designed specifically to be used with MySQL,
so implements transactions on the client side instead of using DB
transactions, but has also been used with Postgres and SQLite.  Otherwise
fairly similar to GLORP in philosophy.  In production use, but still
immature.

Both GLORP and Tantalus can be adapted to use Apple's EOModel files for
mapping metadata.

---
Not Evaluated:

> - GemSqueak
> - SIXX - Smalltalk object XML serializer/deserializer
> - BerkeleyDB Plugin
> - SPrevayler