Opened 17 years ago

Closed 17 years ago

#1606 closed enhancement (fixed)

Improve documentation on OGR SQL (w.r.t MySQL and SQLite)

Reported by: Kosta Owned by: Mateusz Łoskot
Priority: normal Milestone: 1.4.2
Component: OGR_SF Version: unspecified
Severity: normal Keywords: MySQLSQLite OGRSQL
Cc: warmerdam

Description

In the "Non OGR-SQL" section of http://www.gdal.org/ogr/ogr_sql.html I would like to see some statements about the MySQL and SQLite implementations. For example: do they pass through the given SQL command just like the Oracle and PostGIS implementations?

I would say yes, but only if I do not pass in "OGRSQL" as "pszDialect", correct?

And what is the needed/supported keywords/parameters for opening existing or creating new SQLite datasources? Should be documented here: http://www.gdal.org/ogr/drv_sqlite.html

Change History (6)

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added
Component: defaultOGR_SF
Milestone: 1.4.2
Owner: changed from warmerdam to Mateusz Łoskot

Mateusz,

Can you take care of this? We should ensure that per-driver documentation makes it clear when SQL is passed through to the database. The ogr_sql.html could be extended to list some other drivers that pass the sql directly through but it's role isn't primarily to talk about non-ogr sql so we don't want to go into too much detail. Also we have no way to ensure that new drivers get added here.

comment:2 by Kosta, 17 years ago

And an additional question about the implementations of Oracle, MySQL, SQLite & co:

What happens, if I change some attribute values of a feature? Are these changes immediately applied to the underlying database or only after calling OGRDataSource::SyncToDisk()?

If the second case is true, issuing an ExecuteSQL() call before "syncing to disk", the attribute changes are not considered during the SQL evaluation, right?

in reply to:  2 comment:3 by Kosta, 17 years ago

Replying to Kosta:

If the second case is true, issuing an ExecuteSQL() call before "syncing to disk", the attribute changes are not considered during the SQL evaluation, right?

... and is this behavior different for implementations not passing the SQL command through (e.g. the Shapefile implementation)?

comment:4 by warmerdam, 17 years ago

Generally speaking ExecuteSQL() should see features updates after you have called SetFeature() or CreateFeature(). Modifying a feature object in memory (ie. calling SetField()) has no effect on the datastore until you return that feature via CreateFeature() or SetFeature().

comment:5 by Mateusz Łoskot, 17 years ago

Status: newassigned

comment:6 by Mateusz Łoskot, 17 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r11447.

Note: See TracTickets for help on using tickets.