[GRASS-dev] db function needed to check if column exists in table

Hi

to my knowledge no DBMI function exists yet to check if a column exists
in (vector) table.

Suggestions:

     db_get_column(driver, hcolumn,key, &column);
     if (!column)
         G_fatal_error(_("Missing column <%s> in table <%s>"), hcolumn, table);

Or this one (used in r50492, here modified):

      if ((col_type =
           db_column_Ctype(Driver, table, column)) == -1)
           G_fatal_error(_("Column <%s> not found in table <%s>"),
column, table);

I am not familiar enough with DBMI but do see the need to have such a function.
Rationale: the SQLite backend happily accepts nonsensical names and the test
should become a single line rather than the currently used workarounds in
v.to.rast/support.c or v.extrude/main.c or the like.

Markus

On Mon, Jan 30, 2012 at 11:38 AM, Markus Neteler <neteler@osgeo.org> wrote:

Hi

to my knowledge no DBMI function exists yet to check if a column exists
in (vector) table.

Suggestions:

db\_get\_column\(driver, hcolumn,key, &amp;column\);
if \(\!column\)
    G\_fatal\_error\(\_\(&quot;Missing column &lt;%s&gt; in table &lt;%s&gt;&quot;\), hcolumn, table\);

int db_get_column(dbDriver * Driver, const char *tname, const char *cname,
      dbColumn ** Column);

exists in lib/db/dbmi_client/cloumn.c. This function sets *Column to
NULL and returns DB_Failed if the column does not exist.

Try v.extrude in trunk r50546 for an example.

Markus M

Or this one (used in r50492, here modified):

 if \(\(col\_type =
      db\_column\_Ctype\(Driver, table, column\)\) == \-1\)
      G\_fatal\_error\(\_\(&quot;Column &lt;%s&gt; not found in table &lt;%s&gt;&quot;\),

column, table);

I am not familiar enough with DBMI but do see the need to have such a function.
Rationale: the SQLite backend happily accepts nonsensical names and the test
should become a single line rather than the currently used workarounds in
v.to.rast/support.c or v.extrude/main.c or the like.

Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi,

2012/1/30 Markus Metz <markus.metz.giswork@googlemail.com>:

db\_get\_column\(driver, hcolumn,key, &amp;column\);
if \(\!column\)
    G\_fatal\_error\(\_\(&quot;Missing column &lt;%s&gt; in table &lt;%s&gt;&quot;\), hcolumn, table\);

in this case you would probably need to close DB connection before
calling G_fatal_error(). Probably candidate for new error handler (see
[1]) which would close DB connections, close input vector map, and
delete output vector map.

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/handler.c#L26

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

On Mon, Jan 30, 2012 at 12:04 PM, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

2012/1/30 Markus Metz <markus.metz.giswork@googlemail.com>:

db\_get\_column\(driver, hcolumn,key, &amp;column\);
if \(\!column\)
    G\_fatal\_error\(\_\(&quot;Missing column &lt;%s&gt; in table &lt;%s&gt;&quot;\), hcolumn, table\);

in this case you would probably need to close DB connection before
calling G_fatal_error(). Probably candidate for new error handler (see
[1]) which would close DB connections, close input vector map, and
delete output vector map.

There are hundreds of places where G_fatal_error() is called without
closing DB connections. I would rather have the spawning fixed such
that sub-processes are closed if the calling process is closed. This
is working fine on Linux, but not on Windows.

Markus M

Martin

[1] http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/handler.c#L26

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Markus Metz wrote:

>>> db_get_column(driver, hcolumn,key, &column);
>>> if (!column)
>>> G_fatal_error(_("Missing column <%s> in table <%s>"), hcolumn, table);
>>>
>
> in this case you would probably need to close DB connection before
> calling G_fatal_error(). Probably candidate for new error handler (see
> [1]) which would close DB connections, close input vector map, and
> delete output vector map.

There are hundreds of places where G_fatal_error() is called without
closing DB connections. I would rather have the spawning fixed such
that sub-processes are closed if the calling process is closed. This
is working fine on Linux, but not on Windows.

Agreed. An error handler won't help if the process terminates on a
signal.

r50563 (hopefully) solves another potential issue, but I don't know
whether it's "the" issue; I don't think that any of us are
particularly "fluent" with the Windows API.

Ultimately, Windows support will depend upon people who are both able
and willing to develop and debug on Windows. And it sometimes seems to
be an either-or thing; those who can program have working Linux/Mac
systems (and prefer to use them), while those who use Windows
exclusively tend not to be programmers.

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