On 9 Oct, 2007, at 17:27, Andi Vajda wrote:
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.
I'm not saying you want a relational db because it's easier to
migrate. I'm saying that, from a practical perspective, there is no
difference between your "hard compiled" system and what we have
today. Maybe I'm missing the point, though: What are you saying is
different between the two?
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
