Opened 11 years ago

Closed 8 weeks ago

#2194 closed enhancement (wontfix)

Server-side object merge

Reported by: Jonathan Bennett Owned by: rails-dev@…
Priority: minor Milestone: Wishlist
Component: api Version:
Keywords: Cc:

Description

Brain dump follows:

It would be nice if, when "deleting" an object because you're merging it into another or replacing it with a different form, the client could communicate this to the server, which in turn kept a record of this and made this information available via an appropriate HTTP response -- this would be a 302 if the object was merged into another, or maybe a 300 if it was split into many others.

For objects which have really been deleted the server could still return 410.

An example would be a road where each end had been mapped separately as a stub, which are eventually merged into a single Way when the whole length had been mapped. While you could extend one of the stubs to form the new, complete Way, one would have to be deleted. If the server knew it had been merged into another Way, it could return a more helpful HTTP response.

The benefit to the project is that data URLs become more reliable as a way of referring to real-world objects: Even if the data gets munged by various edits, you can still get some useful data back from it.

Change History (3)

comment:1 Changed 11 years ago by Tom Hughes

Component: adminapi

comment:2 Changed 9 years ago by Tom Hughes

Owner: changed from Tom Hughes to rails-dev@…

comment:3 Changed 8 weeks ago by mmd

Resolution: wontfix
Status: newclosed

I'd say this is something for API 0.8 or 0.9. Having predecessor/successor relations across changes that involve replacing nodes by ways is totally non-trivial. It's even not clear how an editor application would collect this kind of information.

I'm closing due to the castle-in-the-sky nature of this issue. This needs to be discussed on a more general level with all parties involved. This can only be outside of an issue tracker.

Closing here.

Note: See TracTickets for help on using tickets.