To clarify one misunderstanding: the attachments are not stored, just the attachments' name and version (number). AFAIK, the attachment history is stored separately.

I know that it is not so efficient to store the complete document, with content and objects, even if there is a small change like a comment added. But this is how it is done now too, and this is a change that tries to do better, not perfect.


On 3/1/07, Ludovic Dubost <ludovic@xwiki.com> wrote:

Hi,

I think it's a good idea to have a versions table. One thing I'm not
sure of is whether this table should hold the master information or just
a cache for the information stored in the revision. If it is a cache it
could not have all the info but just the most important one.
What I'm worried about is the volume of information when there are many
changes. Suppose we get a comment spam of 500 comments. The JRCS
revision system will only add you the actual spam. If you have the
archived info in the table system you get 500 times the size of the
document. And how will you export the whole document including archives.
Would you use RCS or would you have the whole history inside an XML
field inside the document.

One downside of RCS is that you need to parse the whole RCS document to
get the version. But we could solve this by cutting the RCS file in
chunks of 50 versions so that we get faster retrieval. It's true that
this is a little painfull to code.
The cache table with the most important metadata (version, date, author,
comment) would allow to have what we need for getting information about
contributors and number of contributions, retrieving comments at edit time.

Ludovic

Sergiu Dumitriu a écrit :
> Hi,
>
> Sometime ago, there was a discussion regarding how should the document
> history be stored in a better way.
>
> Right now, the complete history is stored as one field in the xwikidoc
> table. From my PoV, this has some major disadvantages:
> - loading an older version requires parsing all the history -> memory
> inefficiency
> - as the documents grow older, loading a document will take a lot of
> time -> time inefficiency
> - queries on archives cannot return just one version, but they match
> the whole document (somewhere in the history, there was a version
> containing "search term")
>
> The blocking issue with storing old version in a different table was,
> at that time, the fact that a document archive should contain all
> information needed for completely restoring the document, like
> content, metadata, objects.
>
> I don't think that is actually an issue. We are archiving document
> versions, but we're joining all versions in one large string. Why
> don't we archive the complete version, but one version per row?
>
> So, the archive table should look like:
> - document name
> - version number
> - language (for translations)
> - content
> - archived metadata (one field, or the same fields as in xwikidoc)
> - archived objects (one field)
> - attachment names and versions
> It is not like storing the version as a normal document is, with
> separate objects and properties, but at least it provides a better
> storage and retrieval mechanism, and it separates a bit the parts of a
> wikidocument - content, metadata, objects.
>
> WDYT?
>

--
http://purl.org/net/sergiu