On 12/03/2010 04:13 AM, Guillaume Lerouge wrote: > Hi, > > On Fri, Dec 3, 2010 at 08:55, Marius Dumitru Florea < > [email protected]> wrote: > >> On 12/03/2010 12:45 AM, Caleb James DeLisle wrote: >>> I now have a working model of attachment storage in the sandbox. >>> >> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/ >>> I can upload and download attachments with it simply by adding the .jar >> file to the /lib/ dir and >>> changing the attachment store in the xwiki.cfg. >>> >>> This introduces a 2 major changes to the storage direction which I want >> to go over: >>> >>> 1. TransactionRunnable. This is a closure (like java.lang.Runnable) which >> does a job inside of a >>> transaction, it also provides hooks for rollback, commit and complete >> events. The underlying concept >>> is that code which is to run inside of a transaction is passed as an >> object to the storage engine >>> where the transaction is opened and it is run. This will make the >> exception catching generic for all >>> storage and Transaction is an interface independent of Hibernate or SQL. >>> See the bottom part of: >>> >> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-filesystem-attachments/src/main/java/com/xpn/xwiki/store/FilesystemAttachmentStore.java >> >> Maybe you should make the start method final. >> >>> NOTE: I have TransactionRunnable as a nested class while it is in >> development and I intend to move >>> it out when it becomes more mature. >>> >>> >>> 2. Filesystem hierarchical storage: An attachment called 30579.jpg a >> document called >>> xwiki:Main.WebHome will be stored in a file at the path: >>> >>> work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg >>> >>> The names are URL encoded for security. The directory ~this contains a >> character which is URL >>> invalid and thus insures that if nested spaces are implemented, a >> document called >>> xwiki:Main.WebHome.attachments will not cause a collision. >>> The "attachments" directory is a directory dedicated to attachments for >> the given document. >>> The "30579.jpg" directory under the attachments directory is dedicated to >> all information related to >>> that directory. This opens the possibility for attachment history to be >> stored along side the >>> attachment content. >> > > Right now, where are all the versions of a given file stored and under which > name? Is there > > work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_1.jpg > work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_2.jpg > work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_3.jpg > > and so on? > > If not, where are previous versions of the file stored?
The versioning store is not written yet but that's about what I plan to do. My plan is to use: work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579~1.1.jpg because the user might attach a file called 30579_1.jpg which would collide with 30579.jpg (version 1) "~" will be escaped by URL encoding which happens to the file name which ensures no collisions. Caleb > > >>> WDYT? >> >> Looks good to me, +1. >> > > Looks promising to me as well... Is there a way I could get a version to > test without having to build XWiki? > > Guillaume > > >> Thanks, >> Marius >> >>> >>> Caleb >>> >>> >>> PS. This code currently contains no tests, I do not want to go any >> further until I know this path is >>> agreed upon. >>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
