Question Use of _UID as a permalink

At the moment _UID is supported by webtrees, but not used. I just found an application which uses _UID as a permalink in the URL: For example: ofb.genealogy.net/famreport.php?ofb=aken...B058A966B114FF5B3C86 uses the unique id in the URL. Would it make sense for webtrees to offer such a permalink as an additional alternative to the URL using the XREF?

For example:

• Pretty URL today: ahnen.hartenthaler.eu/tree/ahnen/individ...ang-von-Goethe-I6164
• New UID permalink: ahnen.hartenthaler.eu/CF89FEB841A944F1B75106AD7A8FCEAD6CF5

The UID is unique, so specifying a tree is unnecessary. If the _UID is part of an INDi or FAM that person or that family should be shown (using the data security rules of webtrees). The same for sources, archives and so on. If an _UID is used more than once on a webtrees site, the first tree or the first public tree should be selected and an error message should be shown. Maybe it should be possible to specify an optional additional tree parameter to avoid such an error message.

What do you think about that?

hermann wrote:

What do you think about that?

Brilliant idea!

So the permalink by uuid will in principle redirect to the regular url. Each page of a first-class object (person, family, media object, note, source, repository, maybe place) includes its permalink to share.

hermann wrote:

If an _UID is used more than once on a webtrees site, the first tree or the first public tree should be selected and an error message should be shown. Maybe it should be possible to specify an optional additional tree parameter to avoid such an error message.

It shouldn't be an error message imho. There are many webtrees users (me included) that have multiple trees containing some overlap. It should give a choice which tree to view, maybe aided by the amount of data available per tree. Just count the number of gedcom lines of the person and the direct relatives as a sort criteria.

Hi Hermann,

in principle, using the UID as a permalink is a good idea. However, the link should also contain the tree information, as identical persons can occur in several trees.

For example:
ahnen.hartenthaler.eu/tree/tree1/CF89FEB841A944F1B75106AD7A8FCEAD6CF5

In addition, a data fix should be deployed for checking identical UIDs within the same tree as an incentive for merging.

> However, the link should also contain the tree information, as identical persons can occur in several trees.

An imported tree may contain _UID fields on all records.
Or just some records.
Or no records.
Or it may even contain the same _UID field on every record!

So webtrees would need to create its own UUID for every record that was imported.

Do these become internal to webtrees, or do we store them in _UID fields.

If you import two copies of the same tree, then the same record in each tree will have a different _UID field.

These are interesting ideas.

The main problem at the moment is that we do not have any search indexes for _UID or other ID fields.
So each time we fetch an individual/family/etc., we would need to search the full text of every table.
This would be very slow.

Adding new search indexes/tables would need database changes. Changing the database structure is not easy.
The current database library (laravel) assumes you know the exact structure of your database so that you can issue exact updates.
But depending on the history of your site, you might not have the same indexes, or they might have different names, or your foreign-keys might not exist, etc.

So, I am currently working on a different database library (doctrine/dbal), which uses a different approach. You tell it the database structure you want, and it works out what changes are needed.

Another problem - which affects both solutions, is that altering a table can be slow - especially on large systems. Adding a column/index to a table can take longer than is allowed on a single web-page request.

There are lots of open issues in the github tracker that require database changes. Once I have the new database library working, I will be able to work on them.

Yes, a new search index in the database is necessary for this new function. So I would like to put it on the waiting list until the new database library is available.

The application that uses my above example, has an _UID in all INDI records. So it can use the permalinks for all persons.

A new imported or an already existing tree may contain

• _UID fields on all records: Yes, this is possible. Perfect.
• Or just some records: Yes, for example only in some of the INDI records. Then you can use the permalinks only for that persons.
• Or no records: Yes, then you need a function to add _UID
• Or it may even contain the same _UID field on every record: That would be erroneous.

I would prefer to use the _UID records and not an internal database field of webtrees because that would allow me to export the tree to another application like the OFB application in my example and use nearly the same URL.

It would be necessary to add a data fix to webtrees that allows the user to add an _UID to all INDI records (or all FAM, SOUR, ... records). But only if there is not already a _UID in that record. I would prefer to call that function explicitly and not automatically when importing a tree. If I need a copy of my tree, I would first generate the _UID in the tree, export that tree and import it into the copy. Now identical persons have the same _UID.

Following Peter: In addition, a data fix should be deployed for checking identical UIDs within the same tree as an incentive for merging. And yes,, it should be possible to add the tree as a (optional?) parameter in the URL.

Following Bert: Yes, the permalink by UUID will in principle redirect to the regular URL.

The initial request here is for INDI and FAM records to have a permalink. I would suggest that ALL records have a permalink as well.

A permalink to _UID is not optimal since it is not a regular GEDCOM tag, I would rather see it use the REFN tag with a REFN.TYPE of “perma”.

norwegian_sardines wrote:

A permalink to _UID is not optimal since it is not a regular GEDCOM tag,

Since GEDCOM 7.0, the UID is a regular tag, as well as for all records and for all events and facts.

For a permalink, we need a unique identifier. REFN is defined in GEDCOM that allowing the same id code to be used for different records.

GEDCOM 7 says:
>A user-defined number or text that the submitter uses to identify the super‐
>structure. For instance, it may be a record number within the submitter’s auto‐
>mated or manual system, or it may be a page and position number on a pedi‐
>gree chart.