I am writing (again) about the Divide and map. Now. The idea of the project is to divide up a big area to organize mapping better. In this note, I will share how I was thinking about the mapping workflow from the beginning, how I finally improved it, and how I hesitated but broke the workflow in the end. And I am sure I did right.
The mapping workflow
The workflow copies a mapathon. Many guys are mapping one area. Few of them are reviewing the work of colleagues. They are locking squares of the area to avoid rewriting the data under their hands.
Since the beginning, it’s possible to lock random or recent square. Mapping guys lock random squares. The reviewing guys lock recent ones to provide feedback to the mappers as soon as possible.
Implementation details
----------------------
Feel free to skip code notes if you are not interested in the code.
There is some background I need to share before showing the SQL query:
- The server is RESTful.
- Changes to squares work the same as git commits.
(It means that the first commit of any square is `to map`. Then mapper locks a random square adding the `locked` commit to the database. When finished, the mapper adds the `to review` commit. Then the `locked` commit is added again by a reviewer who finally adds the `done` commit.)
The important thing is that no one can delete a commit. Just add. Also, there is no square state. Square consists only of area identifier, square identifier, and border. If you need to know the square's "state," you need to look at the square's last commit.
Finally, the query to map random square is:
WITH last AS (
SELECT DISTINCT ON (sid) cid, sid, aid, type, author
FROM current_commits
WHERE aid=$1
ORDER BY sid, cid DESC
),
tomap AS (
SELECT *
FROM last
WHERE type='to map'
ORDER BY RANDOM()
LIMIT 1
)
INSERT INTO current_commits (sid, aid, author, type, message)
SELECT sid, $1, $2, 'locked', 'I am mapping'
FROM tomap
RETURNING sid
