Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
wiki:documentation:devguide:data_access_module [2016/01/14 07:03] gribeiro |
wiki:documentation:devguide:data_access_module [2016/01/19 16:23] gribeiro [Design] |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| As one can see in the class diagram below, the Data Access module provides a basic framework for accessing data. | As one can see in the class diagram below, the Data Access module provides a basic framework for accessing data. | ||
| - | {{:wiki:devguide:dataaccess:dataaccess_class_diagram.png|Data Access Class Diagram}} | + | {{:wiki:documentation:devguide:dataaccess_class_diagram.png?640|Data Access Class Diagram}} |
| It is designed towards extensibility and data interoperability, so you can easily extend it with your own data access implementation. | It is designed towards extensibility and data interoperability, so you can easily extend it with your own data access implementation. | ||
| Line 29: | Line 29: | ||
| * **dynamic linking and loading:** new drivers can be added without the need of an explicit linking. The data access architecture must support dynamic loading of data source driver modules, so that new drivers can be installed at any time, without any requirement to recompile TerraLib or the application. | * **dynamic linking and loading:** new drivers can be added without the need of an explicit linking. The data access architecture must support dynamic loading of data source driver modules, so that new drivers can be installed at any time, without any requirement to recompile TerraLib or the application. | ||
| - | The yellow classes with the names in italic are abstract and must be implemented by data access drivers. Following we discuss each class in detail. | + | The yellow classes with the names in italic are abstract and must be implemented by data access drivers. Following we discuss each class in detail. See the [[http://www.dpi.inpe.br/terralib5/codedocs_5.1.0/d8/d18/group__dataaccess.html|Doxygen documentation for more details]]. |
| + | ===== DataSource ===== | ||
| + | The **DataSource** class is the fundamental class of the data access module and it represents a data repository. | ||
| + | |||
| + | It may represent, for instance, a PostgreSQL database, an Oracle database, an OGC Web Feature Service, a directory of ESRI shape-files, a single shape-file, a directory of TIFF images, a single TIFF image or a data stream. | ||
| + | |||
| + | Each system or file format requires an implementation of this class. | ||
| + | |||
| + | A DataSource shows the data contained in it as a collection of [[:wiki:devguide:dataaccess|Datasets]]. | ||
| + | |||
| + | The information about the data that is stored in a data source may be available through a [[:wiki:devguide:dataaccess|DataSetType]], that contains the dataset name name and its structure/schema. | ||
| + | |||
| + | Besides the descriptive information about the underlying data repository each data source also provides information about its requirements and capabilities. This information may be used by applications so that they can adapt to the abilities of the underlying data source in use. | ||
| + | |||
| + | Each data source driver must have a unique identifier. This identifier is a string (//in capital letters//) with the data source type name and it is available through the method ''getType''. Examples of identifiers are: POSTGIS, OGR, GDAL, SQLITE, WFS, WCS, SHP, ACCESS. | ||
| + | |||
| + | A data source is also characterized by a set of parameters that can be used to set up an access channel to its underlying repository. This information is referred as the **//data source connection information//**. This information may be provided as an associative container (a set of key-value pairs) through the method ''setConnectionInfo''((TODO: we should use a plain connection string through the method ''setConnectionStr'')). The key-value pairs (kvp) may contain information about maximum number of accepted connections, user name and password required for establishing a connection, the url of a service or any other information needed by the data source to operate. The parameters are dependent on the data source driver. So, please, check the driver documentation for any additional information on the supported parameters.((When using a plain string, the information is encoded by a set of key-value pairs separated by an equal sign and each pair is separated by the ampersand (''&'') and they must be URL encoded.)) For instance, in a PostGIS data source it is usual to use the following syntax: | ||
| + | |||
| + | For an in depth explanation, see the [[http://www.dpi.inpe.br/terralib5/codedocs_5.1.0/de/de5/classte_1_1da_1_1DataSource.html|Doxygen documentation of this class]]. | ||
| + | ===== DataSet ===== | ||
| + | |||
| + | For an in depth explanation, see the [[http://www.dpi.inpe.br/terralib5/codedocs_5.1.0/dc/d2c/classte_1_1da_1_1DataSet.html|Doxygen documentation of this class]]. | ||
