[gdal-dev] OGR ODBC Driver and Default Enumeration

Frank Warmerdam warmerdam at pobox.com
Thu Oct 22 01:06:11 EDT 2009


Folks,

This evening I have done some long outstanding work on the OGR ODBC driver
to support tables within schemas reasonable.

   http://trac.osgeo.org/gdal/ticket/1969

Previously the default behavior of the driver was to treat all tables and
views in the ODBC datasource as layers.  For heavy duty RDBMSes like Oracle,
SQL Server this included all the system tables though due to the lack of
proper schema handling the system table "layers" were not actually readable
as normal layers.  That is now fixed.

Enumerating all tables and views as layers can be quite expensive at runtime
- it just takes several seconds to query all the field information for all
these tables and turn it into OGRLayer objects.  In the past my advice to
people has been to list only the tables they need in the OGR datasource
name they connect with.

eg.
ODBC:MyDB,table1,table

This ensures that only the listed tables are queried for details and
speeds things up substantially.  However, I am now wondering if it would
be better to only enumerate tables in the empty/default schema by
default if no table list is provided in the datasource string.  This would
dramatically speed up the connection speed for Oracle, SQL Server, etc,
and also keep huge numbers of useless layers out of people faces in GUI
apps like QGIS.  The main downside is that it would be substantially harder
to find out about potentially useful system tables via the OGR API though
they could still be accessed by listing them in the table list, or
pass through SQL queries.

Does anyone have any opinion on this?  Feel free to reply here, drop me a
note, or add a note to the ticket.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent



More information about the gdal-dev mailing list