21 Oct
2010
21 Oct
'10
8:40 a.m.
On 10/20/2010 12:28 PM, Ludovic Dubost wrote:
Yes.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Le 20/10/10 12:03, Caleb James DeLisle a écrit :
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.
- 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. 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 ?