You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API update gloss code for the Senses checks whether the "new" senses is the "same" as the already existing senses. If nothing has changed, it ignores the senses. (See #1368, #1417)
Use is made of the "package" value retrieved for senses. This is because SignCollect uses this to fetch all the recently updated glosses every five minutes or so. So the "retrieved" senses value of the "package" is compared to the "new" value in the update request.
This is done to prevent "identity" updates.
This is because the "senses updates" removes the old senses and then creates them again, inside a complex transaction.
Make sure the "new" input "string" or "dict" value is normalised in such a way that it matches the Signbank json encoding of the senses offered by the package when they ought to be the same value. To my knowledge this is done. But with the modifications to the "input", this ought to be confirmed. (#1466 )
The text was updated successfully, but these errors were encountered:
Code requirement for #1466, #1461, #1360
The pull request #1485 should fix remaining problems.
The pull request #1499 allows to remove them.
The API update gloss code for the Senses checks whether the "new" senses is the "same" as the already existing senses. If nothing has changed, it ignores the senses. (See #1368, #1417)
Use is made of the "package" value retrieved for senses. This is because SignCollect uses this to fetch all the recently updated glosses every five minutes or so. So the "retrieved" senses value of the "package" is compared to the "new" value in the update request.
This is done to prevent "identity" updates.
This is because the "senses updates" removes the old senses and then creates them again, inside a complex transaction.
Make sure the "new" input "string" or "dict" value is normalised in such a way that it matches the Signbank json encoding of the senses offered by the package when they ought to be the same value. To my knowledge this is done. But with the modifications to the "input", this ought to be confirmed. (#1466 )
The text was updated successfully, but these errors were encountered: