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

Partial updates #85

Closed
rhiaro opened this Issue May 27, 2016 · 8 comments

Comments

Projects
None yet
3 participants
@rhiaro
Member

rhiaro commented May 27, 2016

I coulda sworn we had an issue about this. Correct me if I'm just not seeing it. Right now:

The Update activity is used when updating an already existing object. The object should be modified to reflect the new structure in defined in the update activity.

I'm reading this like Update replaces the object in its entirety. So of the an attribute of the original object is not present in the object of the Update, it will be dropped.

We should have a way to do partial updates so you don't have to rebuild the entire object every time or risk losing parts. And for attributes which can have multiple values, we need to know how to add or remove specific values, as well as adding/removing them all at once.

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro May 27, 2016

Member

I would guess that defaulting to 'partial' update, and having a flag of some kind that says 'replace the whole thing with this' would be easier than the other way around.

Member

rhiaro commented May 27, 2016

I would guess that defaulting to 'partial' update, and having a flag of some kind that says 'replace the whole thing with this' would be easier than the other way around.

@evanp evanp changed the title from Parital updates to Partial updates Jun 6, 2016

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 6, 2016

Collaborator

So we're now deciding that update is always mutation, and to supply a NULL value means to delete that field.

Collaborator

cwebber commented Jun 6, 2016

So we're now deciding that update is always mutation, and to supply a NULL value means to delete that field.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 6, 2016

Collaborator

There's some question about whether or not you might specifically want a value to have NULL as a value?

Collaborator

cwebber commented Jun 6, 2016

There's some question about whether or not you might specifically want a value to have NULL as a value?

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jun 6, 2016

Collaborator

Also it's generally agreed that json patch there be dragons

Collaborator

cwebber commented Jun 6, 2016

Also it's generally agreed that json patch there be dragons

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 9, 2016

Collaborator

Hm. I thought of a reason that this could be a real problem. This seems fine for client to server (I just want to change this field), server to server federation (okay, the other server probably has an instance of this object), but when it comes to server to server federation plus server to client, it could be a real problem!

For instance, say someone on another server changes the name of their post... an object gets sent over the network that contains just that updated name field, nested in the object. Well, I connect to my server, and uhoh! I see an update to an object that my server has seen, but I never have. Furthermore, it might be something that isn't public, in which case I would need something like the proxyUrl in #101 in order for things to happen correctly. I'm not confident that a client will do the right thing here anyway. It's certainly a lot of extra steps.

Updating nested objects is also unclear. If you update an object 3 levels deep in a json structure, are you updating that whole object, or just the outer value?

I think this has real problems and we're likely to get it wrong.

Collaborator

cwebber commented Sep 9, 2016

Hm. I thought of a reason that this could be a real problem. This seems fine for client to server (I just want to change this field), server to server federation (okay, the other server probably has an instance of this object), but when it comes to server to server federation plus server to client, it could be a real problem!

For instance, say someone on another server changes the name of their post... an object gets sent over the network that contains just that updated name field, nested in the object. Well, I connect to my server, and uhoh! I see an update to an object that my server has seen, but I never have. Furthermore, it might be something that isn't public, in which case I would need something like the proxyUrl in #101 in order for things to happen correctly. I'm not confident that a client will do the right thing here anyway. It's certainly a lot of extra steps.

Updating nested objects is also unclear. If you update an object 3 levels deep in a json structure, are you updating that whole object, or just the outer value?

I think this has real problems and we're likely to get it wrong.

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 9, 2016

Collaborator

Okay, it looks like I'm wrong: Pump.io allows partial updates.

So, here's what I think then. Client to server should permit partial updates, as discussed above. But! For server to server communications, and server to client communications, servers/clients SHOULD send along the entire object.

There's a bit of asymmetry there, but I think it will result in the least amount of wrong behavior by clients. WDYT?

Collaborator

cwebber commented Sep 9, 2016

Okay, it looks like I'm wrong: Pump.io allows partial updates.

So, here's what I think then. Client to server should permit partial updates, as discussed above. But! For server to server communications, and server to client communications, servers/clients SHOULD send along the entire object.

There's a bit of asymmetry there, but I think it will result in the least amount of wrong behavior by clients. WDYT?

@jankusanagi

This comment has been minimized.

Show comment
Hide comment
@jankusanagi

jankusanagi Sep 9, 2016

Accepting partial updates from clients while ensuring the whole thing is fully sync'd between servers sounds great =)

jankusanagi commented Sep 9, 2016

Accepting partial updates from clients while ensuring the whole thing is fully sync'd between servers sounds great =)

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 12, 2016

Collaborator

I just pushed 0b46c1c which I believe closes this.

Collaborator

cwebber commented Sep 12, 2016

I just pushed 0b46c1c which I believe closes this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment