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
There are times where the user generates a display in the curator tools, and does not make any modifications to the filters or sort order parameters. Regardless if they were modified or not, they are passed into the API call with their current states. This becomes an issue if the dataset is reuploaded with new metadata, as data groups may change with the new iteration.
My suggestion for future-proofing some of these is to have a flag to detect if the filters or sort order have been modified or touched, and only pass them to the API call if they are modified. This will ensure that they will not break if the dataset itself is modified. This unfortunately will not be backwards compatible with existing curations as the properties have already been saved to database.
The text was updated successfully, but these errors were encountered:
Related to the resolution of #919.
There are times where the user generates a display in the curator tools, and does not make any modifications to the filters or sort order parameters. Regardless if they were modified or not, they are passed into the API call with their current states. This becomes an issue if the dataset is reuploaded with new metadata, as data groups may change with the new iteration.
My suggestion for future-proofing some of these is to have a flag to detect if the filters or sort order have been modified or touched, and only pass them to the API call if they are modified. This will ensure that they will not break if the dataset itself is modified. This unfortunately will not be backwards compatible with existing curations as the properties have already been saved to database.
The text was updated successfully, but these errors were encountered: