On 12/03/2010 05:24 AM, Vincent Massol wrote: > > 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.
If we are never going to implement nested spaces then that plan would work fine. The problem with nested spaces comes when you have a nested space called "attachments" and then you will have a collision. Caleb > >> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
