Restore always returns 0

[serkandurusoy]

Restoring a document returns 0 even on successful restore whereas it should be returning 1 just like it does when softremoved.

[zimme]

I'll look into it as soon as possible

[serkandurusoy]

Great, thanks!

[zimme]

So what I think is going on here is that if you publish a set of posts if will only publish the posts which aren't soft-removed.

Then you soft remove 1 post and that post will no longer be published to the client, because it's soft-removed.

Then when you restore that same post using it's _id, the post will get restored but as it's not in the clients local Posts collection. The restore function running in client code won't restore anything and it will return 0 and then the code running on server will restore it and the client won't get the response of the server call.

I'm looking into re-implmenting the softRemove and restore functions more like that way insert/update/remove is implemented.

[serkandurusoy]

Ah yes that makes sense!

[zimme]

The reason that this works this way is because I allow softRemove and restore to soft-remove and restore documents from client-side calls, even if they aren't published to the client, by specifying the documents _id.

I'll have a closer look at how remove works and if that works like softRemove does now, I'm not changing anything. However I believe it doesn't which is why I'm thinking I should really change softRemove/restore not to allow soft-remove/restore from client side on document which isn't published to client.

[serkandurusoy]

I've given this more thought. I think you should not waste time looking into this.

If we are on the client and we don't have the id of a removed item by normal means, we don't need to be able to recover it by normal means either.

If we are on the client and know the id of a softremoved document, that actually means that we've deliberately subscribed to a publication that sends down those documents to the client, so I guess the client can use a server method for this.

But, I do believe that this should be pointed out in the documentation as a caveat.

[zimme]

I'm just gonna benchmark this against remove and make softRemove and restore work the same way. It might be less convenient BUT I feel that keeping my API as close to Meteor's is the best way to go with these functions.

There's a small change I've already benchmarked this against remove and that's why my functions work the way they do today 😛

But as you said, I need to update documentation either way.

[serkandurusoy]

👍

[zimme]

I've tried to get this fixed, but I'm pretty sure I'll need to do some fundamental changes which are breaking changes in the behaviour of remove and restore and that'll need a major version bump.

I'll try and get this done the coming weekend, hackathon time ;)

[serkandurusoy]

Let me know if there's anything I can do to help :)

[zimme]

After the changes I plan, you won't be able to restore or softRemove document from client unless the documents have been published to the client.

This should sort out the restore returning 0 even if the restore was successful thing, but it'll be breaking changes, as people might be using the restore by id passthrough behaviour that's in play now.

I just need to benchmark against remove first too.

[serkandurusoy]

Well, I'd like to repeat this

If we are on the client and know the id of a softremoved document, that actually means that we've deliberately subscribed to a publication that sends down those documents to the client, so I guess the client can use a server method for this.

You really don't have to cover all the edge cases. Even though I requested this, I now know that my reasoning was based on false pretense.