[xwiki-devs] [Proposal] Introduce a new table BackLinks for solving issues on wiki farms
26 Feb
2019
26 Feb
'19
12:03 p.m.
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(a)xwiki.com
More about us at http://www.xwiki.com
26 Feb
26 Feb
12:08 p.m.
+1
On Tue, Feb 26, 2019 at 12:03 PM Simon Urli <simon.urli(a)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(a)xwiki.com
More about us at http://www.xwiki.com
--
Thomas Mortagne
2:49 p.m.
+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
2:59 p.m.
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(a)xwiki.com
More about us at http://www.xwiki.com
3:25 p.m.
On Tue, Feb 26, 2019 at 2:59 PM Simon Urli <simon.urli(a)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?
--
Thomas Mortagne
Thanks,
Marius
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
2029
days inactive
2029
days old
4 comments
3 participants
participants (3)
-
Marius Dumitru Florea -
Simon Urli -
Thomas Mortagne