Skip to content
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

Renaming documents #143

Closed
nickasd opened this issue Mar 31, 2017 · 13 comments
Closed

Renaming documents #143

nickasd opened this issue Mar 31, 2017 · 13 comments

Comments

@nickasd
Copy link

nickasd commented Mar 31, 2017

Hi and thank you so much for this awesome library. I was wondering whether it would be possible to implement some kind of file manager, so that a client can subscribe to a collection named "files" and get updates whenever a document is added or removed. What is apparently missing is the ability to rename a document. Could this feature be added to a future release or should I store each document's filename as a property in the JSON object?

@curran
Copy link
Contributor

curran commented Mar 31, 2017

I had to implement something similar.

My solution was to assign each document a permanent id, generated using node-uuid, then have the "name" of the document be a mutable property.

@nickasd
Copy link
Author

nickasd commented Apr 3, 2017

Thanks for confirming, that's what I'm going to do.
Out of curiosity, do you use node-uuid on the client or the server? My idea was to provide a static document id on the client (say, "new_file") when creating a new document and replacing it with uuid.v1() on the server, but it seems like the client doesn't even send the request to the server if that document id already exists.

@curran
Copy link
Contributor

curran commented Apr 3, 2017

I'm using it on the client, and depending on its randomness for avoiding collisions.

@nickasd
Copy link
Author

nickasd commented Apr 12, 2017

I was just going to ask how one could efficiently be notified about filename changes in such a scenario and was all excited when I found out about the undocumented sharedb.addProjection(projectedCollectionName, realCollectionName, fields) after having a look at #135. With such a projected collection, I would then be able to create a subscribe query which only notifies about changes to a document's name field.
Unfortunately such a query doesn't fire 'changed' events. It would be interesting to know if this is something in development ... or if there is an alternative solution to this problem.

@curran
Copy link
Contributor

curran commented Jun 15, 2017

FWIW I added documentation for projections in the pending PR #154

Perhaps this issue can be closed? If not, can you clarify the exact issue with ShareDB?

@nickasd
Copy link
Author

nickasd commented Jun 19, 2017

In the documentation you mention addProjection with two different signatures, I think you forgot to remove the third argument from the second example.
I still don't know if the lack of 'changed' events is a bug or not for projections, do you know something about that? Otherwise a client cannot be notified about renamed documents without subscribing to each single one.

@curran
Copy link
Contributor

curran commented Jun 19, 2017

@nickasd Thanks a ton for the close reading! I went back and fixed that error re: different signatures.

I believe, just like with real collections, if you want to be notified when any document changes, you'll need to subscribe to each and every individual document individually, the use on('op', ...). There may be another way that I don't know about.

@nickasd
Copy link
Author

nickasd commented Jun 19, 2017

You're welcome! And thanks for your suggestions.
Subscribing to each document is a possibility, but then each client will have the whole collection of files in memory only to be notified about filename changes. This can be quite inefficient when the collection is big or the client wants to open only a few files.

@curran
Copy link
Contributor

curran commented Jun 19, 2017

Right, it seems like there should be another way that's more efficient. If you use a projection with just the name field, only the name field will be loaded into memory for each document, and I think you can use the Document API on elements of projections, so I think to subscribe to name changes across all documents, you could do it with only loading the projected documents with names only.

But still, it could be a lot of documents. Have you considered using the middleware? You can trigger some code any time a name change flows through the system by adding middleware that checks ops.

sharedb.use('apply', (request, done) => {
  console.log(request.op);
  if(isNameChange(request.op)){
    console.log("name changed");
  }
  done();
});

I'm not sure how this would play out with your use case, but it's one option for listening for changes.

@nickasd
Copy link
Author

nickasd commented Jun 20, 2017

By using the projection I'm able to get all the filenames, but the problem is that in a projection subscription there are no events signalling when a name changes (as opposed to collection subscriptions), only the 'ready' event is fired.
Using the middleware could be a workaround, but then the server would have to notify the clients (on another WebSocket?), handle concurrent filename changes ... and maybe there are other issues I cannot think of at the moment.

@curran
Copy link
Contributor

curran commented Nov 24, 2017

@nateps @rkstedman @josephg [issue tending note] I think this issue can be closed, as it's a question on how to use ShareDB, not a feature request or bug with ShareDB itself.

@rkstedman
Copy link
Contributor

Thanks @curran!

@curran
Copy link
Contributor

curran commented Nov 26, 2017

Thanks @rkstedman !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants