On Tue, 9 Oct 2007, Grant Baillie wrote:
4. implementing a generic database inside another generic database
That was the goal, originally. Not to have a hard compiled app against a
hard compiled relational schema. If Chandler is to become a hard compiled
application with a static schema, where all data types have to be
determined in advance, then of course, the chandler repository is overkill
and can be replaced by some specifically optimized, domain-specific,
schema.
I'm confused: How is what we have (where you have to throw out your data any
time the schema at either of 2 levels changes) different from the "hard
compiled app against a hard compiled relational schema"? (Apart from the word
"relational").
Not throw out. Migrate to a new schema. Just like in a relational database.
If you change the low-level layout (format), core schema, or app schema (table
layout) someone needs to migrate the data. It might be apparently easier in a
relational schema but not so once you've carefully optimized it and duplicated
stuff left and right to get the desired performance. Essentially, it becomes
harder once the 1-1 correspondance between programmer's view (kind/class) and
SQL table is broken.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
