#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: unspecified
Keywords: | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
When trying to create a distance matrix and upload that to a table, I've
stumbled upon what seems to be a very old bug in v.distance:
1) The table cannot be created because of a missing TO_ATTR: case in the
switch statement in vector/v.distance/main.c, line 790.
2) Even when such a TO_ATTR: case is added, the column in the new table is
filled with NULL values. I have not been able, yet, to figure out where
this problem comes from.
#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mlennert):
Replying to [ticket:672 mlennert]:
> When trying to create a distance matrix and upload that to a table, I've
stumbled upon what seems to be a very old bug in v.distance:
>
> 1) The table cannot be created because of a missing TO_ATTR: case in the
switch statement in vector/v.distance/main.c, line 790.
>
> 2) Even when such a TO_ATTR: case is added, the column in the new table
is filled with NULL values. I have not been able, yet, to figure out where
this problem comes from.
The attached patch solves 1) & 2) for dbf and postgresql backends, but not
2) for SQLite. When using an SQLite backend, the trouble seems to come
from the fact that the same database and table are accessed twice. Maybe
some playing around with db_close_database_shutdown_driver might help, but
I haven't had the opportunity to play around with that. Anybody have any
hints about this ?
In any case I find the attached patch useful for the backends where it
works. It's against devel6, but should be straightforward to port to
trunk.
#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Vector | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mlennert):
Replying to [comment:2 mlennert]:
> When using an SQLite backend, the trouble seems to come from the fact
that the same database and table are accessed twice. Maybe some playing
around with db_close_database_shutdown_driver might help, but I haven't
had the opportunity to play around with that. Anybody have any hints about
this ?
I can now confirm that this is a database locking issue. When doing
it works, i.e distance_cancer contains values in the to_cancer column.
I would imagine that this kind of sqlite database locking will be a
problem in other modules as well, so this probably needs a wider solution
than just within this module. Anyone out there with enough experience with
SQLite to attack this ? This is very important if SQLite is to become the
default db backend...
#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Vector | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by neteler):
* milestone: 6.4.0 => 6.4.3
Comment:
Potential answer to the SQLite locking problem:
On Tue, Jul 17, 2012 at 11:58 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
> "When SQLite creates a journal file on Unix, it opens the directory
> that contains that file and calls fsync() on the directory, in an
> effort to push the directory information to disk." [0]
>
> If another process is modifying files or just keeping files open in
> this directory while sqlite calls fsync(), opening the sqlite database
> will fail.
>
> Markus M
>
> [0] http://www.sqlite.org/lockingv3.html
#672: v.distance -a with upload=to_attr and table= option: problems in table
creation and value upload
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.3
Component: Vector | Version: unspecified
Keywords: v.distance | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by mlennert):
Replying to [comment:4 neteler]:
> Potential answer to the SQLite locking problem:
>
> On Tue, Jul 17, 2012 at 11:58 AM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:
> > "When SQLite creates a journal file on Unix, it opens the directory
> > that contains that file and calls fsync() on the directory, in an
> > effort to push the directory information to disk." [0]
> >
> > If another process is modifying files or just keeping files open in
> > this directory while sqlite calls fsync(), opening the sqlite database
> > will fail.
> >
> > Markus M
IIUC, MarkusM has fixed this with r52770. At least for me, in grass7, this
seems to work. Probably should be backported, so leaving this open for
now.