24 Mar
2016
24 Mar
'16
1:48 p.m.
Hi Denis,
On 24 Mar 2016, at 12:48, Denis Gervalle
<dgl(a)softec.lu> 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
<thomas.mortagne(a)xwiki.com
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 <vincent(a)massol.net>
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%…
>>
>> 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