-
Notifications
You must be signed in to change notification settings - Fork 2
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
implement addProject method for MapeoManager class #215
Conversation
7feff26
to
8d3ca6d
Compare
aa29820
to
e6d6f4f
Compare
135b900
to
1dd14f0
Compare
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.
Somewhere along the way the API docs got out of date.
addProject()
is what we would use when receiving an invite, so the param should be the same type as an invite e.g.
addProject(invite: {
projectKey: Buffer,
encryptionKeys: {
auth: Buffer;
data?: Buffer | undefined;
config?: Buffer | undefined;
blobIndex?: Buffer | undefined;
blob?: Buffer | undefined;
},
projectInfo: { name?: string | undefined }
}
Not sure what to do with projectInfo - once we sync we will get the project info from the replicated cores, but in the meantime it would be good to use the name passed here. Suggestions?
If the project you are trying to add already exists then I think maybe throw? And maybe return the |
Also the proto definitions for Invite need updated - encryptionKeys should be required, since we always need an auth core encryption key. I'll do that now. |
7b889a8
to
4e662ae
Compare
1dd14f0
to
5a1dce6
Compare
Ah this make sense. Figured that something about the method params would need to be updated. I have an issue in the core docs repo (digidem/mapeo-core-docs#14) to track changes that need to be made there as a result of the implementation changes we do here, in case that's helpful (I already added it as an item there to address later)
EDIT: discussion with Gregor surfaced the fact that we can't just do the
|
7fa0c9b
to
5851f5c
Compare
640a38e
to
449f5fb
Compare
449f5fb
to
43261cc
Compare
* main: (25 commits) add initial implementation of MemberApi (#232) feat: $blobs.getUrl and $blobs.create methods (#184) chore: update manager e2e tests (#237) feat: add capabilities (#231) feat: coreOwnership integration [3/3] (#230) feat: CoreOwnership class w getOwner & getCoreKey [2/3] (#229) feat: handle `coreOwnership` records in `IndexWriter` [1/3] (#214) fix: adjust storage options for MapeoManager and MapeoProject (#235) implement addProject method for MapeoManager class (#215) implement listProjects method for MapeoManager class (#208) feat: expose blobStore.writerDriveId (#219) implement wrapper client containing createProject and getProject methods (#199) add project settings functionality to MapeoProject (#187) feat: Add encode/decode for project keys [3/3] (#203) feat: update protobuf for RPC [2/3] (#202) chore: move protobuf messages into src/generated [1/3] (#201) feat: Add internal `dataType.createWithDocId()` (#192) chore: explicitly set "mode" opt for encryptionKeys column creation (#186) chore: fix linting and type checking (#183) chore: consolidate encryption key columns in projectKeys table (#181) ...
Closes #209
NOTE: Stacked on #208Lots of implementation questions:
my understanding is that adding the project should update theEDIT: addressedProjectKeys
table in the client db if it's not there. However, how do we get theauth
encryption key if that's the case? (which is required in theencryptionKeys
column value)I'm guessing that we don't want to callEDIT: addressedproject.$setProjectSettings()
after creating the project instance, like we do inmanager.createProject()
. If that's the case, does it still make sense to return the project instance in thisaddProject()
method? doing so seems to cause some issues unless I'm missing an important step:TODO:
Invite