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, |