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.