[xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms
Hi everyone, we currently have some issues when performing refactoring operations on pages that are linked from another wiki page. See: https://jira.xwiki.org/browse/XWIKI-8346 The current implementation of the links is to keep the local name of the current document and to create a reference containing the name of the wiki for the target document, only if it's a document from another wiki. So basically if I have a wiki:A pointing to subwiki:B, I will get a link stored in DB of "wiki", containing: - fullName: A - link: subwiki:B This forces us to currently iterate over all wikis, when we refactor a page to edit all the links on the farm. That's why we currently have an option which is disabled by default: i.e. we don't update backlinks on a farm by default. In order to allow such operation with less performance issues, I propose to add a new table dedicated to store the backlinks: basically this table would store the reversed information as Links, in the target DB. If I take back my example, the table backlinks of "wiki" would be empty, and I get in the table backlinks of "subwiki", the following information: - fullName: B - backlink: wiki:A Then we could load all backlinks of a document just by looking in one table. The impact on performance would be the necessity to update links in two tables when performing a save, but we can mitigate this by first loading the links so we only update what needs to be (currently we delete and recreate all links, each time...). IMO it would really ease the understanding of links and backlinks, solve the issues on farm and help us to maintain this code. + it doesn't break any legacy since we keep the existing Link table. WDYT? Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli@xwiki.com More about us at http://www.xwiki.com
+1 On Tue, Feb 26, 2019 at 12:03 PM Simon Urli <simon.urli@xwiki.com> wrote:
Hi everyone,
we currently have some issues when performing refactoring operations on pages that are linked from another wiki page. See: https://jira.xwiki.org/browse/XWIKI-8346
The current implementation of the links is to keep the local name of the current document and to create a reference containing the name of the wiki for the target document, only if it's a document from another wiki. So basically if I have a wiki:A pointing to subwiki:B, I will get a link stored in DB of "wiki", containing: - fullName: A - link: subwiki:B
This forces us to currently iterate over all wikis, when we refactor a page to edit all the links on the farm. That's why we currently have an option which is disabled by default: i.e. we don't update backlinks on a farm by default.
In order to allow such operation with less performance issues, I propose to add a new table dedicated to store the backlinks: basically this table would store the reversed information as Links, in the target DB.
If I take back my example, the table backlinks of "wiki" would be empty, and I get in the table backlinks of "subwiki", the following information: - fullName: B - backlink: wiki:A
Then we could load all backlinks of a document just by looking in one table. The impact on performance would be the necessity to update links in two tables when performing a save, but we can mitigate this by first loading the links so we only update what needs to be (currently we delete and recreate all links, each time...).
IMO it would really ease the understanding of links and backlinks, solve the issues on farm and help us to maintain this code. + it doesn't break any legacy since we keep the existing Link table.
WDYT?
Simon -- Simon Urli Software Engineer at XWiki SAS simon.urli@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
+1, but since you're adding a new table maybe it's a good idea to have a backlink **type** column. I'm thinking that there are multiple ways in which 2 entities can be linked: wiki syntax link, image syntax, parameter of a macro call, etc. Notice that I mentioned entities. Maybe we shouldn't limit this table to wiki pages. Here's an example: you put a link to an attachment in the value of an object property. This means the object property is linked to the attachment. Thanks, Marius
On 26/02/2019 14:49, Marius Dumitru Florea wrote:
+1, but since you're adding a new table maybe it's a good idea to have a backlink **type** column. I'm thinking that there are multiple ways in which 2 entities can be linked: wiki syntax link, image syntax, parameter of a macro call, etc. Notice that I mentioned entities. Maybe we shouldn't limit this table to wiki pages. Here's an example: you put a link to an attachment in the value of an object property. This means the object property is linked to the attachment.
So you would have: - sourceType - targetType to identify precisely what this backlink represents? In that case shouldn't we put it in link table too?
Thanks, Marius
-- Simon Urli Software Engineer at XWiki SAS simon.urli@xwiki.com More about us at http://www.xwiki.com
On Tue, Feb 26, 2019 at 2:59 PM Simon Urli <simon.urli@xwiki.com> wrote:
On 26/02/2019 14:49, Marius Dumitru Florea wrote:
+1, but since you're adding a new table maybe it's a good idea to have a backlink **type** column. I'm thinking that there are multiple ways in which 2 entities can be linked: wiki syntax link, image syntax, parameter of a macro call, etc. Notice that I mentioned entities. Maybe we shouldn't limit this table to wiki pages. Here's an example: you put a link to an attachment in the value of an object property. This means the object property is linked to the attachment.
I think this improvement can come later since: * you will always need a field with the document reference anyway to find all the entry related to a document you are currently refactoring, you really need to know the type only when you actually start modify the document so new fields can be added to the table later without breaking anything * we don't currently register backlink for attachments or inside xobject properties so those new fields (if really needed) can be discussed when adding support for those
So you would have: - sourceType - targetType
to identify precisely what this backlink represents? In that case shouldn't we put it in link table too?
Thanks, Marius
-- Simon Urli Software Engineer at XWiki SAS simon.urli@xwiki.com More about us at http://www.xwiki.com
-- Thomas Mortagne
participants (3)
-
Marius Dumitru Florea -
Simon Urli -
Thomas Mortagne