[GRASS-dev] r65348: Mapset's tmp dir placement and broken element search

[Glynn Clements]

Vaclav Petras wrote:

> > I am not sure why it must be so on (if files are not on the same
> > filesystem, they can be copied), anyway I changed it in r65436.
> > GRASS_TMPDIR_MAPSET is accepted only by vector library. Martin
> 
> I don't understand why it should be OK for vectors when it is not OK for
> rasters.

For rasters, it's a regression. The cell/fcell and null files used the
tempfile-and-rename idiom from at least GRASS 4.3 (the oldest version
I have) until the last week.

There are plenty of other files which could ideally use the same
mechanism, but as they're much smaller (and faster to write generally,
as they tend to be simply dumps of existing data), it's less of an
issue.

> Anyway, I think that non-atomicity during copy (instead of move) when
> requested (by GRASS_TMPDIR_MAPSET) is not much worse than anything else
> what one must deal with when using GRASS on some advanced configuration.
> For example, if you are writing to several vector maps with attributes in
> parallel, it will take forever (with SQLite). However, if you use
> PostgreSQL (or probably also DBF) as attribute backend, you get great
> performance. Does this mean that you cannot write vectors with attributes
> in parallel and perhaps also rasters to be on the safe side? No, it just
> means that you need to configure your environment according to what you are
> doing.

Database updates should be handled using transactions where available. 
I don't know whether this is already the case; I'm not that familiar
with the vector or DBMI libraries.

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