On 10/20/2010 12:28 PM, Ludovic Dubost wrote: > Le 20/10/10 12:03, Caleb James DeLisle a écrit : >>> - we also have to solve other large items (like attachment history or >>> recycle bin of attachments) >> This is why I favor a generic BinaryStore rather than a change to >> XWikiHibernateAttachmentStore. >> Another issue which will have to be addressed is the memory >> consumption of JRCS for AttachmentArchive. > At the same time we should avoid mixing apples and oranges. We should > not have data with different meanings in different tables. > For Attachment Archive, I'm not against a solution which stops doing > RCS. It has never been efficient anyway.
RCS for attachments never really worked because it does a diff on the XML export of the attachment, which used to put the actual content as one single line with the Base64 encoding of the content. Thus, the diff will simply delete and add the whole attachment content. This means that replacing an attachment of size N with one of size M will require (N+M)*1.33 + a few more bytes to store the difference, which would only take M if we simply store the attachment as-is. This might be improved a bit now since we're splitting the content on 80 byte lines, but still having several lines in common is pretty rare, given that most attachments are binary blobs. >> The fix to http://jira.xwiki.org/jira/browse/XWIKI-5405 has changed >> attachments so that the content >> and meta data are all saved in a single transaction and >> http://jira.xwiki.org/jira/browse/XWIKI-5474 >> prevents documents from being cached on save so we should have no more >> attachments which dissapear >> when the cache is purged. > Great. This will at least make the problem show up right away. > Does 5405 protect us from having the attachment in the attachment list > and have no content ? Yes. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
