Changes between Version 4 and Version 5 of FDORfc52


Ignore:
Timestamp:
Aug 8, 2010, 4:00:20 PM (14 years ago)
Author:
traianstanev
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc52

    v4 v5  
    2525This RFC proposes a convience wrapper API for FDO. The basic features of the API are:
    2626
    27 * Mostly procedural API (unlike FDO Core object oriented, command based structure).
    28   This significantly reduces object lifetime issues, removes the need of refcounting
    29   and eases possible managed wrapper, due to only one single object controlling database connection lifetime.
    30 * Provides shortcuts for commonly used functionality, like spatial query, fetching extents, feature count
    31 * Automatic type conversion (a.k.a duck typing). Unlike core FDO, the API converts automatically between comaptible type
    32   (No more need to switch-case on FdoByte, FdoInt16, FdoInt32, FdoInt64, FdoDecimal, just to get an integer).
    33 * Thread safe connection pooling/caching. This is a common feature that often developers have to implement
    34   from scratch.
    35 * Possibility to provide alternative backend to the API (for example, OGR backend).
    36 * Possibility to implement common features, like coordinate system transformations,
     27  * Mostly procedural API (unlike FDO Core object oriented, command based structure). This significantly reduces object lifetime issues, removes the need of refcounting and eases possible managed wrapper, due to only one single object controlling database connection lifetime.
     28  * Provides shortcuts for commonly used functionality, like spatial query, fetching extents, feature count
     29  * Automatic type conversion (a.k.a duck typing). Unlike core FDO, the API converts automatically between comaptible type (No more need to switch-case on FdoByte, FdoInt16, FdoInt32, FdoInt64, FdoDecimal, just to get an integer).
     30  * Thread safe connection pooling/caching. This is a common feature that often developers have to implement from scratch.
     31  * Possibility to provide alternative backend to the API (for example, OGR backend).
     32  * Possibility to implement common features, like coordinate system transformations,
    3733  in the wrapper layer, in a single common piece of code for all provider backends.
    38 * Automatic backend data source resolution, similar to OGR
     34  * Automatic backend data source resolution, similar to OGR
    3935  (i.e. if the connection string is a path to an SHP file, the SHP provider will automatically be loaded and used)
    4036
     
    6561Column value access by name is also possible using operator[].
    6662
     63<code>
    6764void PrintFile(const wchar_t* path)
    6865{
     
    113110    }
    114111}
     112</code>
    115113
    116114=== Example 2: Bulk copy from one data source to another (e.g. SHP to SQLite conversion) ===
     
    122120target data store.
    123121
     122<code>
    124123void ConvertFDOToFDO(const wchar_t* src, const wchar_t* dst)
    125124{
     
    172171    }
    173172}
    174 
     173</code>
    175174
    176175== Performance Implications ==