On 12/03/2010 09:07 AM, Vincent Massol wrote: > > On Dec 3, 2010, at 2:20 PM, Caleb James DeLisle wrote: > >> >> >> 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. > > Why? I don't see any collision.
"..../attachments/<attachmentname>/<attachmentversion>" You have a document called xwiki:Main.WebHome and you attach a file called myAttach. That goes in xwiki/Main/WebHome/attachments/myAttach/1.0 Now you add a document called xwiki:Main.WebHome.attachments.myAttach.1\.0 and you attach a file called anotherAttach to this document. That attachment would go in: xwiki/Main/WebHome/attachments/myAttach/1.0/attachments/anotherAttach/1.0 xwiki/Main/WebHome/attachments/myAttach/1.0 already exists and it is not a directory. Caleb > > Thanks > -Vincent > >> >> 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
