9 Aug
2012
9 Aug
'12
11:04 a.m.
In case you're interested in the design, here is a very rough (not yet working)
prototype
of attachment storage in Cassandra upon which we might one day model large object storage
in the RDBMS.
https://github.com/cjdelisle/xwiki-newstore/blob/master/xwiki-platform-stor…
Everything is handled in 1MB chunks and each chunk is flushed to the data store before the
next chunk
is created preventing them from building up in memory. The "version" number is
used to make sure no
two concurrent save operations can ever cause the attachment to end in an inconsistent
state even
in a non-transactional data store.
Thanks,
Caleb
On 08/09/2012 04:43 AM, Paul Libbrecht wrote:
Le 9 août 2012 à 10:28, Caleb James DeLisle a écrit :
For loading an attachment piecewise,
OutputStreams are not the only possible solution
but they are (in my analysis) the best.
I absolutely agree to this.
I find the usage of byte arrays should be even deprecated (still doable while staying in
4.x?).
I've been bragging about it from time to time... but could never contribute to it
indeed.
HttpClient does complain everytime you try to allocate entities in byte-arrays. Maybe
that's too explicit but that's effective to force the developer into finding
alternate solutions.
I've seen things slightly more explicit than outputstream and inputstream floating
around, things related to FileUpload if I remember well. In particular, I think it is best
practice to carry the length as far away into the API as possible thus allowing the best
buffering and storage strategy.
Paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs