[GRASS-dev] [GRASS GIS] #2322: v.db.addtable: add sanity check to avoid unreadable column types with SQLite

#2322: v.db.addtable: add sanity check to avoid unreadable column types with
SQLite
-----------------------------------+----------------------------------------
Reporter: neteler | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Database | Version: svn-releasebranch70
Keywords: v.db.addtable, SQLite | Platform: Unspecified
      Cpu: Unspecified |
-----------------------------------+----------------------------------------
Given that SQLite accepts "whatever" type which is eventially
unreadable:

{{{
# Example: GRASS 7.1.svn (nc_spm_08_grass7):~ >
echo "527500.0|165000.0|1" | v.in.ascii input=- output=testpoint

# nonsense type is accepted as being passed on to SQLite:
v.db.addtable testpoint layer=2 columns="name something"
DB settings already defined, nothing to do
Reading features...
  100%
Updating database...
  100%
0 categories read from vector map (layer 2)
0 records updated/inserted (layer 2)

# re-opening fails since "something" cannot be remapped
# to GRASS DB types:
v.info -c testpoint layer=2
Displaying column types/names for database connection of layer <2>:
WARNING: SQLite driver: unable to parse decltype: something
WARNING: SQLite driver: unable to parse decltype: something
WARNING: SQLite driver: column 'name', SQLite type 2 is not supported
INTEGER|cat
}}}

Ouch. The issue came up while creating "mycol doubleprecision"
instead of "mycol double precision".

A solution might be to re-open the table immediately in
v.db.addtable and delete it right away if not readable to
avoid that the user gets stuck with a broken table.

Ideas?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2322&gt;
GRASS GIS <http://grass.osgeo.org>