-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: return shards as array from upload/add
#56
Conversation
Change `upload/add` to return items with a `shards` array instead of expanding them out to many root#shard rows. Stores shards as a String Set in dynamo. Multiple invocations of `upload/add` with the same root store the union of all the shards from each invocation. Fixes #52 License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
View stack outputs
|
Stack outputs updated
|
License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good! I am super happy with new Upload structure 🤩
Tests are failing though
} | ||
|
||
export interface UploadTable { | ||
exists: (space: DID, root: AnyLink) => Promise<boolean> | ||
insert: (item: UploadItemInput) => Promise<UploadItemOutput[]> | ||
insert: (item: UploadAddInput) => Promise<UploadAddResult> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we follow store pattern and use Output for return value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we've not got a consistent pattern yet. The store table abstraction doesn't have enough info to create the StoreAddResult
as the service includes other field like status and the signed url... so we go
StoreAddInput -> StoreAddOutput -> StoreAddResult
whereas in for upload/add
we already have all the info for the service level result. I'll split those types out to match if we need it.
I think maybe we don't need them if we are also storing the UCAN Log Table. But I might be missing out on something. Let's create an issue to get a broader group discussion on that without blocking this PR |
oh my. the test is failing because it takes more than a second for the function under test to write to the db and return the value, so where i give 1000ms grace for an |
License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
License: MIT Signed-off-by: Oli Evans <oli@protocol.ai>
Co-authored-by: Vasco Santos <santos.vasco10@gmail.com>
- update tests and types to handle upload/list items with a shards array property. - update upload/add fn to return an UploadAddResponse as shards out may be more than shards in. - update README see also: storacha/w3infra#56 Signed-off-by: Oli Evans <oli@protocol.ai>
- update tests and types to handle upload/list items with a shards array property. - update upload/add fn to return an UploadAddResponse as shards out may be more than shards in. - update README see also: storacha/w3infra#56 Signed-off-by: Oli Evans <oli@protocol.ai>
Change
upload/add
to return items with ashards
array instead of expanding them out to many root#shard rows.Stores shards as a String Set in dynamo. Multiple invocations of
upload/add
with the same root store the union of all the shards from each invocation.Fixes up type definitions and some tidying up from #48
Removes
issuer
andinvocation
from upload/add response, we're not using them, and there is an open question of how to store them...Question
Fixes #52
License: MIT
Signed-off-by: Oli Evans oli@protocol.ai