On Dec 2, 2010, at 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.
Sounds cool. Note that I haven't read the code. > 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. > > > 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. I don't understand why we need ~this. Why can't we count the number of directories from the end? ..../attachments/<attachmentname>/<attachmentversion> So to know the attachment name it's simply 2 "/" from the end. > 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. bad bad :) Are you saying this wasn't TDD-developed? Oh my gaaawwwd..... -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
