On Mon, Mar 10, 2008 at 4:34 PM, Ivan Krstić <[EMAIL PROTECTED]> wrote: > Where's the issue? You make the existing corpus a constant database, > and provide user modifications and additions as a tiny, human-readable > overlay file that's consulted first on lookups.
That works for a small group tweaking a large database. > It hardly strikes me > as a worthwhile goal to make the user modifications on a fraction of a > percent of the corpus be in-place at the expense of slowing down all > queries noticeably. Is there some use case that demands this mode of > operation? For any (initial) corpus, at some point user modifications are significant. Consider many users revising a small database. Do they have to share updated corpora and "recent modifications" separately, as database and overlay files? For speed, why not have a constant database that is checked on reads, and perform slower queries on "edit" / "update cached term" / "update all"? SJ _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
