[GRASS-dev] [GRASS GIS] #391: SQLite driver doesn't complain enough with stupid mistakes

Glynn Clements glynn at gclements.plus.com
Tue Dec 9 02:05:38 EST 2008


Markus Neteler wrote:

> >  G64:spearf> g.copy vect=archsites,tmp_arch
> >  G64:spearf> v.db.addcol tmp_arch column='x double y double'
> "columns" is a STRING, so in theory there are (other) cases that more than
> two parameters can be listed, e.g. the SQL statements.
> 
> Question: could we add in the parser something like
> 
> opt->pairanswer = YES|NO,
> 
> and enforce pairs in case of YES? This would be useful as well
> for east_north coordinates and such. Default NULL/NO for compatibility.

That is already provided by opt->key_desc. If the key_desc field
contains N commas, answers must be provided in multiples of N+1. This
is commonly used for coordinate pairs.

However, database columns are specified with one answer per column,
containing both name and type separated by spaces.

It would be possible to change the column= option to use key_desc,
requiring it to be entered as e.g.

	column=x,integer,y,'double precision',z,'varchar(50)'.

But I'm not sure whether that helps; I suspect that users might forget
quotes when a type contains spaces or parentheses, whereas the current
syntax means that they're always required.

The main limitation with key_desc is that all answers have to have the
same "type" (opt->type, opt->gisprompt, opt->options, etc). This means
that you can't e.g. combine r.series output= and method= options:

	r.series output=out.mean,out.median,... method=mean,median,...

into a single option like:

	r.series output=out.mean,mean,out.median,median,...

without losing the type-specific input mechanisms in the GUI (the type
would have to be just "string").

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


More information about the grass-dev mailing list