Mark,

> I'm not a Object-Relationship-Model expert, more an end-user.

Thanks for your inquiry. You need to be aware that there are two
different (but overlapping) things that claim the acronym ORM.
The original one is Object Role Modeling, which was created by
Terry Halpin in the 1980's, see www.orm.net and ormfoundation.org.

The newer and more widely known one is Object/Relational Mapping,
which I write as O/RM. It means a data access layer that takes objects
and persists them in a relational database. This is what ActiveRecord
and Og do.

ActiveFacts will do that too, eventually, but first I'm working on the
Object Role Modeling part, which supports the creation of fact-based
models. Fact-based models are essentially sixth-normal form relational
structures, with some higher-level constructs like subtyping etc, and
most importantly, significant support for describing the data
*semantics*.
In fact, I'm using the term "semantic modeling" more and more, as I
find that the important addition of semantics to information models also
benefits process models and other system artefacts. However...

ActiveFacts doesn't yet take a model and transform it into a relational
database design. That's on the cards soon, and isn't terribly hard, but
I'm otherwise occupied...

> DataMapper and Og differ from AR and DRYSql in that they start with
> the Ruby class and try to map that to a DB. Og does this with a
> decorated class definition that otherwise behaves as a normal Ruby
> class.
> With that background it won't surpise you that I'm curios about the
> state of, or intentions of 'translating' Ruby classes to DB's using
> ActiveFacts?
> From reading the tutorial and looking at the example/administration.rb
> I'm wondering if the (decorated) Ruby-class -> AF-Model isn't the
> preferred route?

As you discovered, I thought about it, and decided it's a bad idea.
Although it works ok for defining physical database models (3NF),
the kind of language needed for an *elementary* model is just too far
from the kind of syntax that's possible with a Ruby DSL. Instead...

I'm creating a new query language, the Constellation Query Language.
CQL has many advantages over SQL, the most important one being
that queries written in CQL are immune to the most common kinds
of schema migration that occur, including attribute migration. The
queries are almost plain-language, meaning that they're easy to read.
The difficulties that SQL's join syntax creates simply don't exist in
CQL.

When CQL is done, you'll be able to define your information models in
a few lines of text, and compile those down to a 3NF relational
database.
Queries will also be written in CQL, and dynamically translated into
efficient SQL.

CQL will integrate with Ruby through my "polyglot" gem. With this,
you'll be able to:

require "cql"
require "fred"

and the cql gem will find the file "fred.cql", parse it, and create Ruby
objects and classes from it. This works by "cql" requiring "polyglot"
and
registering the filetype extension ".cql" with polyglot, which uses a
modified "require". IOW, the "model" won't be created in Ruby, but
*compiled to* Ruby at load time (and later, to other languages).

> I'm less familar with DRYSql (though you can read an exchange I had
> with the author on his blog), and have never used AR.

I submitted patches to DRYSql to provide support for multi-part keys for
use with AF's reflection capabilities.

Clifford Heath.