{"action":"closed","issue":{"url":"https://api.github.com/repos/catmaid/CATMAID/issues/919","repository_url":"https://api.github.com/repos/catmaid/CATMAID","labels_url":"https://api.github.com/repos/catmaid/CATMAID/issues/919/labels{/name}","comments_url":"https://api.github.com/repos/catmaid/CATMAID/issues/919/comments","events_url":"https://api.github.com/repos/catmaid/CATMAID/issues/919/events","html_url":"https://github.com/catmaid/CATMAID/issues/919","id":57825751,"number":919,"title":"Explore the idea of a temporal lock on recently edited neuron","user":{"login":"acardona","id":50458,"avatar_url":"https://avatars.githubusercontent.com/u/50458?v=3","gravatar_id":"","url":"https://api.github.com/users/acardona","html_url":"https://github.com/acardona","followers_url":"https://api.github.com/users/acardona/followers","following_url":"https://api.github.com/users/acardona/following{/other_user}","gists_url":"https://api.github.com/users/acardona/gists{/gist_id}","starred_url":"https://api.github.com/users/acardona/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/acardona/subscriptions","organizations_url":"https://api.github.com/users/acardona/orgs","repos_url":"https://api.github.com/users/acardona/repos","events_url":"https://api.github.com/users/acardona/events{/privacy}","received_events_url":"https://api.github.com/users/acardona/received_events","type":"User","site_admin":false},"labels":[{"id":184938698,"url":"https://api.github.com/repos/catmaid/CATMAID/labels/status:%20info%20needed","name":"status: info needed","color":"ededed","default":false},{"id":186236145,"url":"https://api.github.com/repos/catmaid/CATMAID/labels/type:%20discussion","name":"type: discussion","color":"c7def8","default":false},{"id":90716,"url":"https://api.github.com/repos/catmaid/CATMAID/labels/type:%20enhancement","name":"type: enhancement","color":"0b02e1","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2015-02-16T16:37:31Z","updated_at":"2016-12-15T22:35:31Z","closed_at":"2016-12-15T22:35:31Z","body":"As the amount of concurrent reconstructions increases, the likelihood of two or more people editing the same neuron increases too. Adding nodes is fine, but joining a neuron changes the skeleton_id, which may come as a surprise to the other party that is adding nodes: the canvas will still work, but the 3D viewer and other widgets will have the wrong skeleton_id. Splitting could have the same consequences. \n\nOverall these edits on neurons that one is currently editing are surprising. Avoiding the surprise is desirable. One potential way to prevent surprises is to de facto lock a neuron whose skeleton one is currently editing, by preventing edits on neurons that have been recently edited by someone else. The issues are for how long should the lock be in place, and how can the lock not add at least a extra expensive treenode table lookup for the latest edited node by someone else. An additional table with user_id, skeleton_id, time_stamp could simplify the lookup. At least inserting nodes wouldn't have to look up this table, because adding treenodes only depends on the parent treenode existing.\n\nAnother approach could be to avoid locks altogether with a revamped log table where splits and merges are recorded. We would have to find an inexpensive way to sync the client's lists of skeleton IDs to edits in this table, without pushing from the server to the client (never looked like a good idea). Perhaps in the same way that the session cookie is sent to the server with every request we could send as well the set of skeleton IDs currently present in the widgets and return, with every request, a brief map with changed skeleton IDs containing old vs new skeleton IDs. For completeness would require that the nodes_list_tuples for updating the canvas SVG layer doesn't return skeleton_id for every node, but rather these are requested from the server when needed.\n\nNeeds lots of careful thought.\n"}}
{"actor":{"display_login":"aschampion"}}