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

[Ivan Shmakov]

>>>>> Glynn Clements <glynn at gclements.plus.com> writes:

 >>> 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.

	Unfortunately, it doesn't seem to solve the ``rsync after
	g.rename'' problem properly.  The original point behind the new
	layout was exactly its rsync-friendliness.

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

	BTW, what do you mean by full transaction support here?

 > In any case, all of these mechanisms would require substantial
 > changes to a large number of modules.

	I'll try to check whether I could make the new layout available
	under the old API as well.

[...]