FilOzone/pdp#250 is now merged and waiting to be deployed, it has:
findPieceIdsByCid(uint256 setId, Cids.Cid calldata pieceCid, uint256 startPieceId, uint256 limit)
public
view
returns (uint256[] memory pieceIds)If we look at pieceStatus as one place where this matters, recently edited in: #655, we end up doing:
const exists = activePieces.pieces.findIndex((piece) => piece.cid.equals(parsedPieceCID)) > -1
// ...later...
pieceId = pieceData.id
With findPieceIdsByCid deployed, that becomes a single targeted call:
const pieceIds = await findPieceIdsByCid(client, { dataSetId, pieceCid, startPieceId: 0n, limit: 1n })
const exists = pieceIds.length > 0
const pieceId = pieceIds[0]No more fetching the entire piece list. For large datasets this is the difference between a call that could fail and one that processes minimal data.
This only comes when we get an ABI update to match deployed contracts of course. Also there may be other places we need to do the CID->ID mapping where this can help.
FilOzone/pdp#250 is now merged and waiting to be deployed, it has:
If we look at
pieceStatusas one place where this matters, recently edited in: #655, we end up doing:With findPieceIdsByCid deployed, that becomes a single targeted call:
No more fetching the entire piece list. For large datasets this is the difference between a call that could fail and one that processes minimal data.
This only comes when we get an ABI update to match deployed contracts of course. Also there may be other places we need to do the CID->ID mapping where this can help.