MaxNoetzold / y-mongodb-provider

Mongodb database adapter for Yjs
MIT License
52 stars 10 forks source link

is there a way to retrieve the documentId & change the searching for document via id instead of docName and how would i extend the schema? #14

Closed abdou6666 closed 6 months ago

abdou6666 commented 7 months ago

I am building a collaborative app using socketio / mongodb and yjs like notion so i need to pressist the users who can access the document in db with their access level any idea how you would deal with these issues .I couldn't find a straight forward way to deal with these issues with your provider ( i need to be able to establish relation between the pressisted document & the creator). This is the work around i'm trying to do but i still need to be able to have access to the document via id instead of docName (doc name isn't unique) & after the creation of document i need to be able to access the the pressisted doc with id

document {
    _id,
    documentName:string;
    data:BSON;
    documentDetails : documentDetailsId,
    snapshots ?: [docV1, docV2]
}

documentDetails: {
    usersAccess : [
        {
             READ_ACCESS: boolean,
             WRITE_ACCESS: boolean,
             userId:  userId,
        },
    ],
    oragnizationOwner : _orgId,
    userOwner : userId,
    _id :  id,
}
raineorshine commented 7 months ago

You can make a documentName unique by adding a uuid.

abdou6666 commented 7 months ago

i thought about it but it still doesn't eliminate the issue that i need to modify the schema (which i believe its hard coded in utils.js createDocumentUpdateKey ) i need the document name attribute & i need a way to establish relationships between the documentDetails and the yjs-mongodb document

raineorshine commented 7 months ago

YJS providers like y-mongodb-provider that use room names are basically just hash tables. If you embed a unique userId in a documentName, then you can derive any number of Docs, e.g. abc-data, abc-access, etc. The server can control access by extracting the userId and a bearer token from the request and authenticate before serving up the requested Doc.

Unless you have more complex querying requirements, you should be able to tweak the documentName to look up related Docs. Unless I am misunderstanding.

abdou6666 commented 7 months ago

let me explain my use case: I'm trying to build collaborative app like notion which has different access management based on what organization users belongs to (users can invite others orgs to collaborate or just guests...) , also the owner can invite/restrict the access to a certain team/individual within their organization with (read/write permissions)

in order to make these access managements effecient i have decided to create another collection which will contains all these data documentDetails . and i would love to change the schema in a way that allows me to do that but i cant find a way since even when creating document "joining a room" the api doesn't return mongodb document instead it returns ydoc instance with the updates if it already exist else it return empty ydoc so cant retrive the mongodb ydoc id with making extra query.

Also i would like to make the schema something along these lines.

collection => YJS-Documents { _id, documentUpdates : [...update1,...update2], documentDetails : { ...access controll }, documentName, ownerId }

I don't think the current implementation allows this flexibility.

raineorshine commented 6 months ago

y-mongodb-provider is only for persisting Y.Docs. To persist custom data, use a general purpose MongoDB adapter. Or, model everything inside Y.Docs.

I still think you can make the documentName unique and use that as the primary/foreign key instead of _id.

MaxNoetzold commented 6 months ago

To close this for me, you could add additional data using the meta data functions. Personally, I wouldn't do it.

For managing user access to the ydocs, I always use an extra collection with the docName as a unique ID. When a client wants to connect, I first check if they have access to the room/doc they want to access and then either load the doc from y-mongodb-provider or not.

So, in my opinion, you have to change y-websocket (or whatever you are using) and not this provider as it is. As @raineorshine correctly wrote, it's only for persisting the data.