| 25 | | Enable the FDO API to support SQL pass-through commands that return an FDO feature reader, referencing a proper FDO schema, not simply an FDO data reader. The feature reader will contain proper geometry properties, relations and associations. This enhancement is also intended to allow client applications that use FDO Feature Readers to code their applications in a generic manner so that data coming back from Select or SQL Pass Through statements can be processed in a uniform manner, thus reducing complexity, cost |
| | 25 | Enable the FDO API to support SQL pass-through commands that return an FDO feature reader, referencing a proper FDO schema, not simply an FDO data reader. The feature reader will contain proper geometry properties, relations and associations. This enhancement is also intended to allow client applications that use FDO Feature Readers to code their applications in a generic manner so that data coming back from Select or SQL Pass Through statements can be processed in a uniform manner, thus reducing complexity, costs and time to implement. |
| 29 | | SQL pass-through deals with physical schema. There is no parsing and what is identified are physical schema tables, columns, functions, commands, etc. SQL can be any SQL command, not just select, but any DML (select, insert, update, delete) or any DDL (create, drop, alter, …). However, FDO feature reader deals with FDO logical schema, which is at a different conceptual level. It’s mixing these levels that causes some difficulty for applications using the FDO API. |
| | 29 | In general, the intent of SQL pass-through is to deal with physical schemas. There is no parsing of the SQL statements, and what is identified are physical schema tables, columns, functions, commands, etc. The SQL statement can be any SQL command, not just select, but any DML (select, insert, update, delete) or any DDL (create, drop, alter, …). However, FDO feature readers deal with FDO logical schemas, which is at a different conceptual level. It’s mixing these levels that causes difficulty for applications using the FDO API. Applications are required to use different code pathways to handle select statement as opposed to direct SQL execution. If clients could use the result of both these types of operations in a generic routine or component, such as a Data Table or Symbolization packages, applications would be provided a much more seemless and dynamic mechanism on which they can can build and extend their applications. |
| 33 | | We can break down the SQL pass through selects into a couple of categories. One category would be selecting data that really isn’t related to any of the FDO schema classes, e.g. selecting from system tables or views (e.g. select from Oracle’s mdsys.cs_srs table, select stuff from dual or SQL Server’s sys.indexes, etc. Spatial predicates are quite a bit different.). |
| 34 | | |
| 35 | | Even if we consider cases where the select is from a table that contains feature or feature related data, what does it mean to return a class definition for that data? Do we reverse engineer the select results and try to find the FDO class definition that seems to match it, that is one of the class definitions that you would get back from FDO’s describe schema? Do we just make up a class definition that may not even exist in FDO’s Describe Schema? If the select is from a single table, we possibly could find the class definition that is based on that table and use it. However, then we have to match up the columns being selected with properties in the logical schema, which may be slightly different – then we’re mixing physical schema and logical schema together (e.g. class names may not be the same as table names, property names may not be the same as column names, there may be additional computed columns, the user may not have selected the pkey columns – should we add them automatically?, etc.). Granted that in many cases, these would be virtually identical, but we can’t guarantee it and have to be able to handle the general case. Maybe we just reverse engineer a class definition from the selected data and not try to match up any existing FDO class? We would have to handle this anyway since a select may not match up at all with an existing class, such as selecting from a table with an owner that is different from the connected data store (e.g. connect to data store called Denver and select from Boulder.Roads – the schema may or may not be similar to Denver.Roads. Even worse, what happens if the user turns around and tries to update one of the returned objects – they’d have to get back to Boulder.Roads and not just try to update the FDO Roads feature class. So, this would have to be a different feature class.) It sounds like we’d manufacture a new class definition unless we could determine with certainty that the select is on a table that matches one of the already defined fdo classes. (An interesting case is “select r.* from roads r where r.length > 50”.) |
| | 33 | We can break down the SQL pass through selects into a couple of categories. One category would be selecting data that really isn’t related to any of the FDO schema classes, e.g. selecting from system tables or views. For example: select from Oracle’s mdsys.cs_srs table, select stuff from dual or SQL Server’s sys.indexes, etc. Even if we consider cases where the select is from a table that contains feature or feature related data, what does it mean to return a class definition for that data? Do we reverse engineer the select results and try to find the FDO class definition that seems to match it, that is one of the class definitions that you would get back from FDO’s describe schema? Do we just make up a class definition that may not even exist in FDO’s Describe Schema? If the select is from a single table, we possibly could find the class definition that is based on that table and use it. However, then we have to match up the columns being selected with properties in the logical schema, which may be slightly different – then we’re mixing physical schema and logical schema together (e.g. class names may not be the same as table names, property names may not be the same as column names, there may be additional computed columns, the user may not have selected the pkey columns – should we add them automatically?, etc.). Granted that in many cases, these would be virtually identical, but we can’t guarantee it and have to be able to handle the general case. Maybe we just reverse engineer a class definition from the selected data and not try to match up any existing FDO class? We would have to handle this anyway since a select may not match up at all with an existing class, such as selecting from a table with an owner that is different from the connected data store (e.g. connect to data store called Denver and select from Boulder.Roads – the schema may or may not be similar to Denver.Roads. Even worse, what happens if the user turns around and tries to update one of the returned objects – they’d have to get back to Boulder.Roads and not just try to update the FDO Roads feature class. So, this would have to be a different feature class.) It sounds like we’d manufacture a new class definition unless we could determine with certainty that the select is on a table that matches one of the already defined fdo classes. (An interesting case is “select r.* from roads r where r.length > 50”.) |
