Hi Clifford,

Thanks for the prompt and detailed response...

--- In information_modeling@yahoogroups.com, Clifford Heath
<clifford.heath@...> wrote:
>
> 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.
>

Thanks for the clarifiation.

> 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...
>

Ok, I think this point comes up later - but I may misunderstand what
you mean in describing ploygot.
It is a point I to tried to make with the DRYSql author... AR and Og
are the same in terms of your use (persisting), but are opposites in
terms of where you 'start' - and that sometimes is not a choice one has :)
No criticism of polygot or AF implied!

> ActiveFacts doesn't yet take a model and transform it into a relational
> database design.

OK its not clear if you mean a Fact based model, or a Ruby
AF-decorated-class model.

> That's on the cards soon, and isn't terribly hard, but
> I'm otherwise occupied...

There seems to be a large Ruby community interested in 'persistence',
there maybe enoguh people to help out on an initial effort?

> > 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

OK that sounds very interesting. After emailing I looked at the
ORM-Metamodel.pdf and it looked like trying to map a Ruby class
to/from that schema there might be a better place to start. Obviously
I don't understand all the operation or relations flagged there, but
it seemed that the Og decorations would be much simpler...

> 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.
>
... however, I was stumped on how you'd (simply) query field(s) :)

> 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.

So it sounds like the answer would be to construct the CQL using Og
and hand-off the query generation to
you CQL2SQL interpreter.

> 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"

OK, here is where Og differs from DrySQL - in Og's case when you
start-up the DB is empty (until you save data), this corresponds to
having an empty CQL file.
So it sounds like Og would need to create a CQL-model
definition, then feed (save-require) that to polygot - correct?

> 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).

Hmm, A fair enough starting point. It sounds like where DrySQL
mandated you start with a SQL definition, AF will mandate starting
with a CQL definition - which is fine, Og, etc will probably evolve to
translate some decorated ruby class (or more perhaps a class instance)
to CQL, and it sounds like that will be much simpler than the current
SQL - a big step forward :)

All sounds very promising, do you have any feel for when the CQL
definition/specification might be in public beta form - the sooner the
Og, etc groups can start working on it :)

Thanks again for all your efforts.

Mark

> > 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.
>