Re: [xwiki-devs] [proposal] Filesystem based attachment storage.

I now have a working model of attachment storage in the sandbox. http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-… 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-… 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.

WDYT? Caleb PS. This code currently contains no tests, I do not want to go any further until I know this path is agreed upon.