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

[GRASS GIS]

#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>
GRASS GIS <http://grass.osgeo.org>