Hi Denis, > On 24 Mar 2016, at 12:48, Denis Gervalle <[email protected]> wrote: > > +0 > > As Thomas said, it would be better to also fix the issues, this should not > be that hard. > There is also other aspects that deserve attention: > - migrating users, that should be warned and provided better way to > migrate than a snippet IMO.
> - the fact that user data will no more be in a single place, and that user > may miss the permanent directory for their backup, especially because it > does not contains other precious information so far. We should raise more > attention on that point. FTR I’ve documented this a long time ago at: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Backup Use cases: * UC1: The user upgrades to latest version of XWiki and merges the xwiki.cfg file * UC2: The user installs a new version and imports a XAR containing all his pages (including attachments). For UC2 nothing to do. For UC1, there are several options: 1) We convert Caleb’s snippet into a DB migrator and move the attachments out of the DB at startup 2) We don’t do anything at startup but we notice that there are attachment content in the DB and we show a "Distribution Wizard”-like UI to convert at the first request (for admins), using the code Caleb’s snippet. We would put explanations about the backup warning you mentioned. What would be the best would be to refactor the DB migrators so that they can have an associated UI, which would be a "Distribution Wizard”-like UI. Any better idea? Now all this is theoretic since there’s nobody with the time to work on any of this AFAIK, so we can create jira issues about it but if we want to progress we need to turn on FS-attachments by default. > This second point is quite important IMO, this is why I am not really +1, I > actually prefer limitation and safety, but I understand why we want to > change. This proposal is about moving forward. We’ve been wanting to have FS-based attachments the default for several years now and we haven’t done it for all those reasons. It has not worked in making us fix those issues so far. So the idea is to go forward, make it the default and then improve. You’re not blocking so that’s good. We can move forward :) Thanks -Vincent > On Thu, Mar 24, 2016 at 12:08 PM, Thomas Mortagne <[email protected] >> wrote: > >> +0 >> >> I feel that we should first fix the two issues you mentioned. The >> second one should not be too hard to fix (it's just about listening to >> WikiDeletedEvent and do some cleanup I guess). >> >> On Thu, Mar 24, 2016 at 11:35 AM, Vincent Massol <[email protected]> >> wrote: >>> Hi devs, >>> >>> It’s been a very long time that Caleb has implemented fileystem storage >> and we still see people regularly stuggling to attach largish attachments >> to their wiki. I think it’s time that we make it the default even if the >> implementation is still not perfect. >>> >>> Namely here are the opened issue related to filesystem store: >>> >> https://jira.xwiki.org/issues/?jql=component%20%3D%20%22Storage%20-%20File%20System%20Attachment%22%20AND%20project%20%3D%20XWIKI%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC >>> >>> Tha main 2 issues are: >>> - XWiki.DeletedAttachments shows nothing when filesystem attachments are >> enabled. >>> - FS Attachments does not delete files when a subwiki has been removed >>> >>> I’m proposing for the moment to add a warning to the deleted attachments >> tab on AllDocs when fs attachment is on. >>> >>> I think the pros outbalances the cons. WDYT? >>> >>> Here’s my +1 >>> >>> Thanks >>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
