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-store-datanucleus/xwiki-platform-store-datanucleus-blob/src/main/java/org/xwiki/store/blob/datanucleus/internal/BlobSaveTransactionRunnable.java 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
