[Proposal] Introduce a new table BackLinks for solving issues on wiki farms

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Introduce a new table BackLinks for solving issues on wiki farms

Simon Urli
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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Introduce a new table BackLinks for solving issues on wiki farms

Thomas Mortagne
Administrator
+1

On Tue, Feb 26, 2019 at 12:03 PM Simon Urli <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Introduce a new table BackLinks for solving issues on wiki farms

Marius Dumitru Florea
In reply to this post by Simon Urli
+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
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Introduce a new table BackLinks for solving issues on wiki farms

Simon Urli


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
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Introduce a new table BackLinks for solving issues on wiki farms

Thomas Mortagne
Administrator
On Tue, Feb 26, 2019 at 2:59 PM Simon Urli <[hidden email]> 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
> [hidden email]
> More about us at http://www.xwiki.com



--
Thomas Mortagne