Content
View differences
Updated by Judith Roth about 2 months ago
Follow-up of ##73334
When the web app or the mobile app renders work packages it needs to decide (based on the setting) which ID to render for work packages. Either the database ID in the "classic" mode or the semantic ID in the project-based work package ID mode.
<br>
**Option A) Add a method in WorkPackage which returns the value based on the setting (= "decide on the fly")**
\+ easy to implement
\+ nothing needs to be saved to the database and kept in sync when switching the setting
\- maybe a little bit slower, since the setting needs to be queried for (almost) each request which involves a work package
If necessary it could be optimized by caching the setting between requests
<br>
**Option B) Use a separate column** `**user_facing_identifier**` **(name is WIP, better suggestions are welcome) (= "decide upfront")**
\+ faster on read
\- needs to be set on write (e.g. in the migration job and each time the semantic identifier changes)
\- when switching from "project-based work package IDs" to "database based IDs" we need a migration job to change this column
<br>
**Option C)** `**def user_facing_identifier = identifier || id**` **\+ **+ clear out identifiers when switching back to classic**
Removing the identifier but keeping the registry table even when switching back to classic still allows us to resolve semantic IDs when back in classic mode.
\+ fast on read
\- when switching from "project-based work package IDs" to "database based IDs" we need a migration job to remove the work package identifiers
\- when switching from "project-based work package IDs" to "database based IDs" and then back to "project-based work package IDs" we have to make sure to reuse the old sequence numbers even when work packages were already moved out of the project which had a sequence number before.
\- masks errors in "project-based work package IDs" mode (not having an identifier is an error in that mode)
When the web app or the mobile app renders work packages it needs to decide (based on the setting) which ID to render for work packages. Either the database ID in the "classic" mode or the semantic ID in the project-based work package ID mode.
<br>
**Option A) Add a method in WorkPackage which returns the value based on the setting (= "decide on the fly")**
\+ easy to implement
\+ nothing needs to be saved to the database and kept in sync when switching the setting
\- maybe a little bit slower, since the setting needs to be queried for (almost) each request which involves a work package
If necessary it could be optimized by caching the setting between requests
<br>
**Option B) Use a separate column** `**user_facing_identifier**` **(name is WIP, better suggestions are welcome) (= "decide upfront")**
\+ faster on read
\- needs to be set on write (e.g. in the migration job and each time the semantic identifier changes)
\- when switching from "project-based work package IDs" to "database based IDs" we need a migration job to change this column
<br>
**Option C)** `**def user_facing_identifier = identifier || id**` **\+
Removing the identifier but keeping the registry table even when switching back to classic still allows us to resolve semantic IDs when back in classic mode.
\+ fast on read
\- when switching from "project-based work package IDs" to "database based IDs" we need a migration job to remove the work package identifiers
\- when switching from "project-based work package IDs" to "database based IDs" and then back to "project-based work package IDs" we have to make sure to reuse the old sequence numbers even when work packages were already moved out of the project which had a sequence number before.
\- masks errors in "project-based work package IDs" mode (not having an identifier is an error in that mode)