On 6/14/07, Andreas Balke [Digiden GmbH] <[EMAIL PROTECTED]> wrote:
the important point (and first question) is that our schema is very likely to change. that means we will have 'revisions' of documents whereas each revision has its own, slightly different, schema. structuring the documents itself wouldn't be a problem i guess, as we could define an 'id' and 'rev' as unique in combination. but how can we handle the revision dependent schema? is there a good way for such thing?
Make changes to the schema in a backward compatible way. You can easily add new fields to a schema without any impact to existing documents. However, if you change the type of an existing field, or how it's analyzed, then it doesn't make sense for documents before the change and after to coexist (both sets would not be searchable in a consistent manner).
* the second big problem is also related to the versioning and its changing schemas. assume we will have a lot of documents that are built of a document type 'Foo' rev 1. now we decide that the schema of Foo changes, the documents, already stored, become invalid somehow. to solve this, we will create some kind of update procedure that fits all documents to the new schema.
The easiest way is to simply delete and reindex all the docs that should change.
will there be a way to solve this problem without fetching all Foo:rev:1 documents and re-importing them as Foo:rev:2 documents? as i write this, it seems to me that this is a stupid question since there is no change interface.
There is a change interface in JIRA, as long as all of the fields originally sent are stored. -Yonik
