I think it would be a nice addition to have a custom field type that behaves like a sorted set of unique values. Then via UI and API you should be able to add / remove values from the set of values.
Use case: Consider a custom issue field named "customer" and you want to use it to keep track of customers which have experienced a given exception. The exception itself could be identified by a hash/unique-id that is also stored as custom issue field. That way you could keep track of something like:
issue #1: showing the stack trace and having custom fields exception-id: <some unique hash 1>, customers: customer1, customer3, customer4
issue #2: showing the stack trace and having custom fields exception-id: <some unique hash 2>, customers: customer4
As a workaround one currently has to use the API to fetch the customers field (defined as simple string field), deserializing it into a set of strings, adding a new customer string and then serializing it again so you can update the field via API.
Robin Shen commented 2 years ago
So the only benefit of this "sorted set" field is to guarantee uniqueness of values compared to multi-line text field?
jbauer commented 2 years ago
The benefits are:
values are guaranteed to be unique
it is sorted so that you can visually find a value in the UI more easily
the tool that interacts with the OneDev API is a little more decoupled from the JSON representation as it does not need to deserialize and serialize the field value. For example a multiline string could be an array of lines or a single string with newline characters.
It saves one API call because the tool that interacts with the OneDev API can directly add a value to the field without first fetching existing values. OneDev will handle uniqueness.
One thing that just came to my mind is: How does OneDev API behave if multiple requests try to modify the same issue concurrently? Will every request but one fail, because you use some sort of optimistic locking? Will every request succeed and the individual edits are effectively merged? Take for example multiple application server hosts, each running a tool/daemon that reports issues via OneDev API. It could happen that all those want to update same issue concurrently.
Robin Shen commented 2 years ago
Currently there is no optimistic lock when update issues. The last update will overwrite updates made by others. To my understanding, concurrent updates happen rarely and also there are change history for each update.
For your use case, update lock is also not necessary if sorted set field is available, as multiple servers can simply append customer record to that particular field via API without overwriting each other.
Hi,
I think it would be a nice addition to have a custom field type that behaves like a sorted set of unique values. Then via UI and API you should be able to add / remove values from the set of values.
Use case: Consider a custom issue field named "customer" and you want to use it to keep track of customers which have experienced a given exception. The exception itself could be identified by a hash/unique-id that is also stored as custom issue field. That way you could keep track of something like:
issue #1
: showing the stack trace and having custom fieldsexception-id: <some unique hash 1>
,customers: customer1, customer3, customer4
issue #2
: showing the stack trace and having custom fieldsexception-id: <some unique hash 2>
,customers: customer4
As a workaround one currently has to use the API to fetch the
customers
field (defined as simple string field), deserializing it into a set of strings, adding a new customer string and then serializing it again so you can update the field via API.