Person Alternate names not used in search, Person view

[dsblank]

The Person object has a list of alternate names. These do not show, and are not used in a search.

Two options:

1. create a new table, and use that for Person.
2. at least search those fields (harder, as it is a nested list)

The problem with 1 is that the number of names is different from the number of people. Does it matter?

[romjerome]

I do not know if the problem is common, but for alternate place names on gramps, one solution was to deal with the model. gramps-project/gramps@5cd646d So, it becomes a "display" issue and no more a "search" one. On the other hand, there is maybe one limit by using one "too common" separator like a comma. Anyway, we do not often have a name with a comma.

…

-------------------------------------------- En date de : Jeu 12.1.17, Doug Blank <[email protected]> a écrit : Objet: [GenealogyCollective/gprime] Person Alternate names not used in search, Person view (#19) À: "GenealogyCollective/gprime" <[email protected]> Cc: "Subscribed" <[email protected]> Date: Jeudi 12 janvier 2017, 14h11 The Person object has a list of alternate names. These do not show, and are not used in a search. Two options: create a new table, and use that for Person. at least search those fields (harder, as it is a nested list) The problem with 1 is that the number of names is different from the number of people. Does it matter? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dsblank]

@romjerome We could stick all of the names in a single field (as the commit you point to shows), but that will not make searches or ordering fast. In fact, it would make them slower. Also, it is confusing when searching for a name, and the matching row doesn't show the criteria. I think the right solution is to actually use a bit of relational databasing, and do a JOIN between the person table, and a new name table. That will solve all of the problems identified, keep searching fast, and the displayed data informative.

[dsblank]

This turned out to be really easy to fix. I have a prototype, but not yet complete.

1. First, one can make a VIEW in SQL that looks just like the person table, but it has a row for each primary + alternate_name. Something like: db.dbapi.execute("CREATE VIEW name_person AS SELECT * from person, name WHERE person.handle = name.handle ORDER BY surname, first_name;") But don't include the secondary name fields from person. The name table will have those. The order will depend on the display_name format? Maybe have no order... can there be indexes on views?
2. In the actual selection, simply use the name_person table rather than person. Everything should work fine.
3. Can we have a display_name that works in Python and SQL? That way, the column shown will exactly match the order. Perhaps another use of the ast.
4. Make sure to update the name_person table when person data changes.