[Andi == [EMAIL PROTECTED] on Fri, 6 May 2005 13:12:55 -0700 (PDT)]
Andi> Repository format changes are only part of the problem.
Ah, excellent point. I was indeed trying to refer to the more general
problem of "Chandler upgrades" vis-a-vis the roadmap. "Repository and
the stuff inside it :)"
Andi> I could add support for repository format evolution which is
Andi> much much simpler to implement...
It seems best for the problem were viewed generally, as a big
functional area ("data preservation?"), such that as some point,
people would need to start caring about upgrades.
Calendar data does seem relatively simple and the right place to
start, given the existence of the well-established ics interchange
format. The rest of the data isn't as easy, and I'm not offering
solutions here. I don't underestimate the difficulty of the problem,
as it includes import systems, export systems, inter-schema encodings,
schema migration logic, and sometime intractable migration problems.
Lisa> For 0.6 requirements, so far we've figured that it's
Lisa> acceptable for dogfood users to have to export and import
Lisa> their data manually in order to upgrade.
I feel export/import is perfectly acceptable. As long as it works :)
Even lossy import/export is ok, as long as people know what they are
going to lose.
The "big idea" is that the roadmap and specs should say something
about "data preservation" between version upgrades. My thought is
that this functional area starts with some simple approaches like
import and export, and with specific data types (like ics as Lisa
suggests). And starting with dogfood/0.6, users should know which of
their data is at risk.
Probably categories of data could be laid out on the roadmap, such
that 0.6 supports calendar "data preservation" only, 0.7 supports
calendar and tasks, 0.8 supports calendar, tasks, events, and notes,
etc. Perhaps eventually "automated schema migration for all
OSAF-provided parcels" at some specific release number, like 1.0
(pre-1.0 would be better so that migration processes are tested before
a 1.0 final).
Hopefully, none of the schemas ever change and none of this comes into
play ;)
The community could perhaps help here with migration scripts, if the
pre-change and post-change schemas are documented sufficiently.
There's a standard data management methodology sometimes used in
relational databases. One builds a series of scripts which know how
to migrate between point-releases. The database itself records which
schema version it currently is. If there's a jump in schema versions,
the scripts are run, one at a time, to migrate to each point release
in sequence. (Easier than a script that knows how to migrate between
any two arbitrary versions.)
Given that the repository has multiple schemas within it, you'd
probably need a script for each schema type/point-release combination.
First stab, I'd say these scripts could be external and manually
applied the first couple times this comes up. Maybe eventually
Chandler would know how to run the scripts automatically (or import
them), and check for needed schema migrations upon start.
It seems too early to have all this worked out, or to care much with
code, but it's getting close to being appropriate for a roadmap and a
general plan of record.
Hard problem, and I don't even know the half of it. Sorry I brought
it up :)
-- [EMAIL PROTECTED]
"One cannot mark the point without marking the path."
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
