David,

You do not have to create the entire schema before starting your
application. In fact you don't care for the schema at all when
developing using Og. During the development phase you can alter your
classes and Og automatically adapts the schema for you. In this phase
you generally don't have any real data to care about.

Btw, Og can work just like AR if needed. Lets say you have a live Blog
application with the following class used to store Posts:

class Post
  property :title, :body, String
  belongs_to User
end

Lets say you want to add a new field in the database called
create_time. Just use you favourite SQL editor to alter the table and
then add the following line to your code:

class Post
  ...
  property :create_time, Time
end

Extremely easy to do. Moreover, it is relatively easy to automate this
procces  for most common cases. A future version of Og will
automatically adapt the schema for a live database.

While I am at it, let me point out some advantages of Og over AR:

- DRY: you can use Ruby's OOP features to build your tables using
inheritance and mixins.

- DRY: you only define your relations (associations) once. In AR you
define the relations in SQL (foreign keys etc) and in Ruby code
(associations)

- uses standard Ruby objects and not beutified hashes.

- you can switch the backend RDBMS by changing one line of code.

- complex patterns like nested_sets/nested_elements can be fully
encapsulated (In AR you have to know the pattern and manually add
columns to the schema)

- You have access to full property/relation metadata for all backends.

- The schema is generated automatically for you.

- generates more optimized code for the managed objects.

I am also working on 'Og-Reloaded'. A brand new implementation of the
low level code and carefully designed changes to the API to support
many many new features.

Stay tuned for an *impressive* new release! 

regards,
George.