[GRASS-dev] modifying the dblink it require to re-build the topology

[Pietro Zambelli]

On Tuesday 12 Nov 2013 20:37:24 you wrote:
> >> I know that it can be annoying to have to create new maps, but at
> >> the same time it is a failsafe that makes sure that even if you
> >> make a mistake in the call to v.category, you still keep your
> >> original data.
> > 
> > yes, it is particularly annoying, because the GRASS db driver is
> > pretty slow copying data from one table to another. Maybe we
> > should
> > add a flag that skip to copy the attribute tables.
> 
> That could be an option, yes.

Ok, done in r58202


> > On the other hand, the tables are already there, we need only to
> > link the geometry features to the existing table.
> 
> No, if we have a new map it should use a different attribute table
> than the old map.

I don't agree I prefer to avoid to have several copy of the same thing 
on my hard-disk, but I can understand your logic. :-)


> > Anyone against this new flag/option?
> 
> I'm not against the flag as it seems a reasonable option to me, but
> I think that the performance issue should be solved as well. From
> what I see in the code, I have the feeling that v.category might be
> bitten by the same "bug"/problem as the one Hamish just reported
> for v.what.rast [1], so possibly it is feasible to improve the
> performance.

Yes, I think that we have a huge problem in the DB drivers, but I 
don't have time right now to understand where the problem is. 

In general I try to avoid to use the C API of the DB as much as 
possible, using directly the python API.

I think that the Attribute table, could gain in usability too if avoid 
to use v.db.select, and start to use directly the python API...
and I think should avoid to load the whole table and load only the 
first 250 rows [0].

Best regards

Pietro

[0] http://trac.osgeo.org/grass/ticket/2124