Changes between Initial Version and Version 1 of FDORfc69


Ignore:
Timestamp:
Aug 12, 2014, 7:04:29 AM (10 years ago)
Author:
jng
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc69

    v1 v1  
     1----
     2= FDO RFC 69 - Enhanced OGR Provider =
     3
     4This page contains a request for comments document (RFC) for the FDO Open Source project. 
     5More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.
     6
     7== Status ==
     8 
     9||RFC Template Version||(1.1)|| 
     10||Submission Date||12 August 2014||
     11||Last Modified||12 August 2014||
     12||Author||Jackie Ng||
     13||RFC Status||draft||
     14||Implementation Status||in progress||
     15||Proposed Milestone||FDO vNext||
     16||Assigned PSC guide(s)||||
     17||'''Voting History'''|| ||
     18||+1|| ||
     19||+0|| ||
     20||-0|| ||
     21||-1|| ||
     22 
     23== Overview ==
     24
     25This RFC is for enhancing the capabilities of the OGR provider and improving its reliability
     26
     27== Motivation ==
     28
     29The OGR provider is very barebones in terms of FDO capabilities, this makes it difficult to author layers from OGR Feature Sources in MapGuide as we can only render/stylize from OGR feature attributes as-is as the provider lacks support for FDO expression functions that let us format/shape this data during layer stylization.
     30
     31Also the OGR provider lacks a basic unit test suite, which gives us no objective baseline as to the reliability of this particular provider.
     32
     33== Proposed Solution ==
     34
     35The OGR provider will be enhanced with FDO Expression Engine support. The OGR expression capabilities will now return the full suite of functions supported by the FDO Expression Engine.
     36
     37The Expression Engine will be used for both Select and SelectAggregates commands. However, use of the Expression Engine will only happen outside of the following cases:
     38
     39 * SelectAggregates with single property or aggregate function and no FDO Filter
     40   * `Count()` will internally issue the following OGR SQL: `SELECT count_expr FROM feature_class`
     41   * `SpatialExtents()` will internally use `OGRLayer::GetExtent()`. Where supported, fast extent (`bForce = FALSE`) is used. Otherwise we brute force (`bForce = TRUE`)
     42   * Single property with distinct = true will internally issue the following OGR SQL: `SELECT DISTINCT prop_name FROM feature_class`
     43 * Select
     44   * Expression Engine will not be invoked if the select command has no computed identifiers
     45
     46This RFC will also fix some defects in the provider that either already existed or were discovered during the implementation of this RFC:
     47
     48 * #885: Use fast extent where possible for `FdoISpatialContextReader::GetExtent()`
     49 * `FdoIConnection::Open()` should fail if `DataStore` property is not specified
     50 * Executing any FDO Command should fail if connection is not open
     51 * OGRLayer pointers do not have their internal iterators reset before select/insert/update/delete, causing potential inconsistent results when executing multiple FDO select/insert/update/delete commands in succession on the same connection
     52
     53We will also implement a basic unit test suite for the OGR provider to exercise Expression Engine support and key provider functionalities.
     54
     55== Test Plan ==
     56
     57Ensure the new test suite passes on both Windows and Linux.
     58
     59== !Funding/Resources ==
     60
     61Community