Signbank / Global-signbank

An online sign dictionary and sign database management system for research purposes. Developed originally by Steve Cassidy/ This repo is a fork for the Dutch version, previously called 'NGT-Signbank'.
http://signbank.cls.ru.nl
BSD 3-Clause "New" or "Revised" License
19 stars 12 forks source link

Signbank API: Allow to update gloss/lemma when there is max one gloss connected #1243

Closed rem0g closed 1 month ago

rem0g commented 4 months ago

As we want to change glosses because of wrong order in A,B,C,D suffix we want to fix the order via Signbank API, only allow glosses name/lemma name to be changed when there is not more than one gloss connected. If there is more than one, then the update should be done at Signbank website.

susanodd commented 4 months ago

Okay, this can be done.

susanodd commented 4 months ago

Do we want this to ignore case? I've made it so it is case-insensitive.

I'm also working on the update for annotations.

The code has evolved over many many years for updating annotations and lemmas. In the past, it was sometimes not allowed to update something because it partially matched something else. For example, if there was already a gloss that had one of the languages empty, it would not allow the creation of a new gloss with both languages where one was the same as the non-empty one. (This is due to the way the database evolved. There are still glosses with some languages empty.)

So for example suppose this (lemma) combination exists (created in the past when empty was allowed):

A, _

and (in the past) this also exists:

A, B

Does this cause an error? Or are the combinations unique? (In the past, these were allowed)

In the past, it was allowed to create the new A,B because it differs from A, (A with empty) But then now it becomes impossible to "fix" A, and make it become A,B because that got allowed as a new combination and both are different.

I'm not entirely sure how to implement the update to allow things that should be allowed but also not allow other things. So this will need to be revised on a trial and error basis. So if you come across something that generates errors, then the code may need to be revised to allow patching some older glosses. (It's not possible to test all existing glosses during development.)

We also have the case of Lemmas without Glosses. So if there are "no glosses" for a lemma, but it matches a "new" gloss, should this be "caught" and used for the new gloss, since it matches?

susanodd commented 4 months ago

This is almost done. It ended up needing three different kinds of lookups for the language fields, since they are referred to by different kinds of keys.

susanodd commented 4 months ago

@rem0g this is live on signbank-dev now.

The language fields for Annotations and Lemmas are there (using the same keys as for creating a gloss).

Will you try out some of your updates on signbank-dev ? If a lemma is shared it reports this and it's not possible. There are additional checks if the language fields are already in use. It will report errors in the returned json as before.

It needs to be tried out some more to make sure all potential constraint violations are caught and not executed. Otherwise there can be a partially executed update. (I put the "save" for the language fields inside try-excepts to prevent a constraint violation crash. Hopefully there are sufficient checks and error reporting to avoid exceptions.) Kindly see if the new fields work as you want them to.

susanodd commented 4 months ago

This is on signbank now.