From: Clifford Heath <no.spam@...>
Date: 2007-04-04T17:00:17+09:00
Subject: Re: ActiveFacts (was "ORM is the ...")

Sam Smoot wrote:
> Just a heads-up since feedback from this group would be appreciated:
> I've implemented that in my DataMapper project.

(CC'ed into information_modeling - DataMapper is on
RubyForge for those folk).

It looks interesting Sam. I've not got very far into
reading it, but I like what I see. It's not heading
in the same direction as ActiveFacts, but we still
have some goals in common. Perhaps there's some room
for collaboration?

I have a couple of plans for AF that goes somewhat
against the tide of O/RM's, based on my experience
from building a very successful AR-style O/RM in C#:

* I don't believe in dynamic reflection from the DB.
   If reflection is needed it should be a manual thing
   that yields a schema file of some sort. DB schema
   don't have enough scope for documenting the original
   intent and conceptual structure - a simple list of
   tables, columns, FK's and indexes isn't a sufficient
   basis for writing good programs. Instead, the whole
   database schema should be generated from a higher-
   level schema that *is* properly annotated so that
   effective code can be generated, and result sets
   have an appropriate structure. (... and I certainly
   don't believe you should have to do a relational
   schema, an object hierarchy, *and* a set of XML
   mapping files, like iBatis for example!)

* I don't believe in fetching whole records, or in
   fetching from only a single relation (including a
   view) in one operation. Applications too often don't
   need that, and it makes lazy programmers who do it
   anyhow. Query results should be structured so they
   can reflect the sum of all the data that must be
   fetched in response to a single user action.

* I think that every row and value fetched should be
   traceable back through the query to the schema.
   IOW you can look at this value "42" and find out
   what the question was :-). This last goal is a bit
   demanding considering with AF, the query is made
   against the fact-based schema, translated to one
   or more SQL queries, potentially cached into a
   stored procedure, processed with parameters into
   one or more tabular result sets, then re-assembled
   into a graph that reflects the structure of the
   original query.

The idea here is that (for example in a Rails context)
you take the parameters from the user's context and
any submitted values, you run one query, and you get
the entire hierarchical result set for rendering the
next view. The result set is structured appropriately
too, so it can be mapped to a view that's dynamic, it
can wrap itself around a number of similar result sets.

If that sounds interesting, lets talk.

Clifford Heath.