Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

retrieve files with status only ready #365

Closed
wants to merge 1 commit into from

Conversation

blankdots
Copy link
Contributor

@blankdots blankdots commented Jan 23, 2024

in the database the latest status might not always be the ready status, this restricts that so that we retrieve files with status ready.

even though the file-mapping is done, when retrieving the file it is good to only get files in status ready indifferent from when that was recorded.

@blankdots blankdots self-assigned this Jan 23, 2024
@blankdots blankdots force-pushed the bugfix/only-show-ready-files branch 3 times, most recently from 0d70648 to 682c5cf Compare January 23, 2024 21:54
@blankdots blankdots requested a review from a team January 23, 2024 21:58
@blankdots blankdots marked this pull request as ready for review January 23, 2024 21:58
@pontus
Copy link
Contributor

pontus commented Jan 24, 2024

Looks fine as such, but just to check; there's no way we can go from ready to a state where the file should no longer be accessible? (I'm not sure what e.g. deprecate means for access.)

@blankdots
Copy link
Contributor Author

blankdots commented Jan 24, 2024

Looks fine as such, but just to check; there's no way we can go from ready to a state where the file should no longer be accessible? (I'm not sure what e.g. deprecate means for access.)

we have disable for that (https://github.com/neicnordic/sensitive-data-archive/blob/main/postgresql/initdb.d/01_main.sql#L122) ... but first the dataset needs to be deprecated (https://github.com/neicnordic/sensitive-data-archive/blob/main/postgresql/initdb.d/01_main.sql#L157)

Edit:

ah I see what you are saying, this solution might not be ideal 🤔 - I will put it back in draft

@blankdots blankdots requested a review from a team January 24, 2024 06:17
@blankdots blankdots marked this pull request as draft January 24, 2024 06:22
@blankdots
Copy link
Contributor Author

i suspect we have this because use assume the events happen in an order, but from what i see from the db it gives me verified as the latest event instead of ready - so i think we need to have another approach to this query for the sync pipeline

@pontus
Copy link
Contributor

pontus commented Jan 24, 2024

It may be a bug I don't see right now, but in theory it seems to me that's where the ORDER BY comes in - we should probably respect access if the latest event (first if sorted by some timestamp descending) is ready or enabled. But maybe that state check shouldn't be in SQL but in go land?

But did I understand correctly that you're seeing behaviour consistent with the query not returning the latest event?

@blankdots
Copy link
Contributor Author

discussed in the chat and we will solve this by refactoring the queries and making use of the file_references and dataset_references tables as well as the sync use case will need to wait for file verification before marking the files as ready

@blankdots blankdots closed this Jan 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants