[GRASS-dev] what if: a new GRASS directory layout?

[Glynn Clements]

Ivan Shmakov wrote:

>  > To make concurrent access work, updating a map would need to be an
>  > atomic operation, so that any module which reads the map sees either
>  > the "before" version or the "after" version, and never sees an
>  > "in-progress" version.
> 
> 	And that's simple.  It's only the current layout of the GRASS
> 	database directory that makes it hard.  The new layout may be
> 	like the following:

[snip]

A simpler (and less radical) solution is to simply all elements of a
map in a common directory. Then, you replace the directory as a whole
rather than individual files. ISTR that this is already planned for
the future.

The downside is that you can't atomically replace a directory in the
same way that you can a file. You have to rename the destination
first, which leaves a small window when the map doesn't exist. But a
transient state with no map is still better than the current situation
of a transient state with an inconsistent map.

Full transaction support would be nice, but I don't know if it's worth
the substantial effort involved in implementing it.

In any case, all of these mechanisms would require substantial changes
to a large number of modules. And there's still the issue of vector
maps, which are often updated in-place.

-- 
Glynn Clements <glynn at gclements.plus.com>