feat: index file requests, files and BSPs storing them #220
Conversation
| } => { | ||
| let bsp = Bsp::get_by_onchain_bsp_id(conn, bsp_id.to_string()).await?; | ||
| let file = File::get_by_file_key(conn, file_key.as_ref().to_vec()).await?; | ||
| BspFile::create(conn, bsp.id, file.id).await?; |
There was a problem hiding this comment.
Why are we inserting instead of deleting?
links234
changed the title
| @@ -80,4 +80,15 @@ impl Bucket { | |||
| .await?; | |||
| Ok(bucket) | |||
| } | |||
|
|
|||
| pub async fn get_by_onchain_bucket_id<'a>( | |||
There was a problem hiding this comment.
Not specific to this PR, but are we not storing the Bucket root?
There was a problem hiding this comment.
Not in this PR, no. I was planning to add root for both buckets and BSPs in another PR.
Is this fine?
There was a problem hiding this comment.
Yeah that's fine. But we have to be aware that until then we want be able to use the main functionality of our indexer.
| pub peer_id: i32, | ||
| } | ||
|
|
||
| impl File { |
There was a problem hiding this comment.
I think it is important to add a get_by_bucket. That is actually the main reason why we have an indexer in the first place.
There was a problem hiding this comment.
Agree. You want to add it in this PR when we will also use it?
There was a problem hiding this comment.
Add it in this PR if possible
| file_key, | ||
| new_root: _, | ||
| } => { | ||
| File::delete(conn, file_key.as_ref().to_vec()).await?; |
There was a problem hiding this comment.
Isn't this deleting the file from the database if just one BSP stops storing it? That would be wrong.
| pub file_id: i32, | ||
| } | ||
|
|
||
| impl BspFile { |
There was a problem hiding this comment.
From what I understand, this links a File to a bsp_id, so that we only store the File information once, but then we have several BSPs that reference it as being a part of their forests, right?
There was a problem hiding this comment.
Yes.
We will have multiple entries here, 1 for each BSP storing the File. Also there are delete triggers setup in Postgres so that if any of the BSP or the File is deleted the relationship entry from this table is also deleted.
| /// Table that holds the Files (both ongoing requests and completed). | ||
| #[derive(Debug, Queryable, Insertable, Selectable)] | ||
| #[diesel(table_name = file)] | ||
| pub struct File { |
There was a problem hiding this comment.
Don't we want to store the BSPs storing this file? It's one of the main reasons for the indexer.
| .await?; | ||
| } | ||
| pallet_file_system::Event::StorageRequestRevoked { file_key } => { | ||
| File::update_step( |
There was a problem hiding this comment.
Shouldn't we delete it here?
| .await?; | ||
| } | ||
| pallet_file_system::Event::StorageRequestExpired { file_key } => { | ||
| File::update_step( |
There was a problem hiding this comment.
If it has no BSPs here, we should delete it
Co-authored-by: Facundo Farall <[email protected]>
No description provided.