On 12/02/2010 11:45 PM, 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
> 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.

+0.5 (I need to take a closer look at this, but my initial feeling is 
that this is a good approach).

>
> 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

+1 (I already talked abut this on IRC with Caleb).

> 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.

This is bad. Tests should drive development, since they are the 
specification of what needs to be done, and they are also the validation 
that what was done is correct.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to