feat: active_deals table
#9
Conversation
Signed-off-by: Miroslav Bajtoš <[email protected]>
Signed-off-by: Miroslav Bajtoš <[email protected]>
| sector_id INT NOT NULL, | ||
| payload_cid TEXT, | ||
|
|
||
| UNIQUE (miner_id, client_id, sector_id, piece_cid, piece_size) |
There was a problem hiding this comment.
This is my current understanding of what must be unique about every deal.
We can also leave out this index until we start writing to this table and then create the index based on what we see in the claim events.
Note that there is no primary key constraint in this table. We can change the UNIQUE constraint to become the primary key.
@NikolasHaimerl What do you think?
There was a problem hiding this comment.
Is it only possible to store a piece cid inside the same sector once?
There was a problem hiding this comment.
I am not sure, TBH.
The docs say that one sector can contain multiple pieces.
I can imagine that it's possible to accept two deals from two different clients that want to store the same data, and pack that data into a single sector. The current UNIQUE index supports that. I have no idea whether this can ever happen.
Also, IIRC, the current practice is only one piece per sector.
I see two paths forward - we can reach out to core FIL developers (maybe in #fil-lotus-dev and ask for clarification, but that can delay our effort. Alternatively, or until we get the answer, let's design the constraint in such a way that it can support the data (even payload/deals) we see now.
Maybe it's best to drop the constraint entirely until we get a better understanding.
Thoughts?
There was a problem hiding this comment.
If the same client wants to store the same piece of data in the same sector then this would invalidate our assumption about uniqueness.
I think we can move forward without this constraint. I don't think we have much to gain by keeping it.
Depending on how we want to query the data later on it might also be favourable to use a Document based database instead of a relational database for this kind of task.
It does not block us from bringing out a first version that supports DDOs though. It is merely a performance and efficieny matter IMHO.
There was a problem hiding this comment.
I removed the constraint in 49c69d4
Signed-off-by: Miroslav Bajtoš <[email protected]>
Create a table to store active deals. Add a dummy test to show client code
writing and reading data from this new table.
Links: