[mapserver-dev] Layer names in OGR connection strings (undocumented feature causing problems)

[Daniel Morissette]

Note that since the parsing code uses CSLTokenizeStringComplex(), in the 
case of OCI connections (below) and the example from 
http://trac.osgeo.org/gdal/ticket/4885 one could likely work around the 
issue by enclosing the first part of the connection string inside 
quotes, e.g.

CONNECTION 
'"OCI:userid/password at database_instance:table,table",ogr_layer_id'

I realize that dealing with string escaping this way is nasty and may 
not work for all cases.

I am not sure about the impact of removing support for this way to 
specify the ogr layer id which I knew about as well without knowing 
whether it was documented or not. It's really hard to tell how many 
users have come to rely on it over time and I'd hate to break backwards 
compatibility if we can avoid it.

Daniel


On 13-03-04 5:29 PM, Smith, Michael ERDC-CRREL-NH wrote:
> Comma separated table names is also part of the OCI connection
>
> "OCI:userid/password at database_instance:table,table"
>
> http://www.gdal.org/ogr/drv_oci.html
>
> From: Brent Fraser <bfraser at geoanalytic.com
> <mailto:bfraser at geoanalytic.com>>
> Organization: GeoAnalytic Inc.
> Date: Monday, March 4, 2013 5:25 PM
> To: Tamas Szekeres <szekerest at gmail.com <mailto:szekerest at gmail.com>>
> Cc: "mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>" <mapserver-dev at lists.osgeo.org
> <mailto:mapserver-dev at lists.osgeo.org>>
> Subject: Re: [mapserver-dev] Layer names in OGR connection strings
> (undocumented feature causing problems)
> Resent-From: Michael Smith <michael.smith at usace.army.mil
> <mailto:michael.smith at usace.army.mil>>
>
> Tamas,
>
>    No doc that I know of.  I knew of the technique of adding
> comma-separated table names to connection strings from years ago when I
> was trying to improve the performance of an ODBC connection
> (http://www.gdal.org/ogr/drv_odbc.html). Stating the table names
> relieves the driver from enumerating all the tables (and views etc) in
> the schema.  Maybe I had reviewed the source code; I can't recall...
>
> Best Regards,
> Brent Fraser
>
> On 3/4/2013 2:20 PM, Tamas Szekeres wrote:
>> Brent,
>>
>> Could you point me to the documentation where this syntax is
>> mentioned? Is this specific to OGR tile indexes?
>>
>> Best regards,
>>
>> Tamas
>>
>>
>>
>> 2013/3/3 Brent Fraser <bfraser at geoanalytic.com
>> <mailto:bfraser at geoanalytic.com>>
>>
>>     Tamas,
>>       if I understand correctly you are talking about connection
>>     strings like:
>>
>>             CONNECTIONTYPE OGR
>>             TILEINEX "PG:dbname='PN2010_0911' host='thinkcentre1'
>>     port='5432' user='PN2010_0911' password='PN2010_0911',images"
>>
>>     note the comma and table name at the end.
>>     See
>>     http://lists.osgeo.org/pipermail/mapserver-dev/2011-April/011194.html
>>
>>
>>     Best Regards,
>>     Brent Fraser
>>
>>     On 3/3/2013 2:09 PM, Tamas Szekeres wrote:
>>>     Hi,
>>>
>>>     According to a commit (made 11 years ago) in rev1370
>>>     <http://trac.osgeo.org/mapserver/changeset/1370>  the OGR
>>>     connections strings are being split by the comma separators, see
>>>     the following fragment in msOGRFileOpen:
>>>
>>>          papszTokens = CSLTokenizeStringComplex( conn_decrypted, ",",
>>>     TRUE, FALSE );
>>>
>>>         if( CSLCount(papszTokens) > 0 )
>>>           pszDSName = CPLStrdup( papszTokens[0] );
>>>         if( CSLCount(papszTokens) > 1 )
>>>           pszLayerDef = CPLStrdup( papszTokens[1] );
>>>
>>>     This behaviour causes issues if the syntax of the connection
>>>     string may normally expect commas, like with the issue:
>>>     http://trac.osgeo.org/gdal/ticket/4885
>>>
>>>
>>>     Does it make sense to split the connection strings this way?
>>>
>>>     According to the OGR driver documentation
>>>     <http://mapserver.org/en/input/vector/ogr.html> the layer
>>>     definitions should go to the DATA section and not to the
>>>     CONNECTION section.
>>>
>>>     I'd be in favour of removing this fragment from the code but I'm
>>>     not sure about all consequences.
>>>
>>>
>>>     Best regards,
>>>
>>>     Tamas
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     mapserver-dev mailing list
>>>     mapserver-dev at lists.osgeo.org  <mailto:mapserver-dev at lists.osgeo.org>http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>


-- 
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000