On Thu, Mar 24, 2016 at 2:48 PM, Vincent Massol <vincent(a)massol.net> wrote:
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.
There's no guarantee that the issues will be fixed after we enable File
System attachments by default, unless we put in on the roadmap (with
someone assigned to it), but then what stopped us from putting it on the
roadmap before?
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.
We may be going forward but we introduce regressions. So I'm not fully
convinced, +0.
Thanks,
Marius
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs