Difference between revisions of "MapGuide RFC 5 - Enhanced Join Support"
(→Status) |
|||
| Line 15: | Line 15: | ||
This proposal is to support additional functionality to feature source joins for chained joins, inner joins, and 1-to-many support. | This proposal is to support additional functionality to feature source joins for chained joins, inner joins, and 1-to-many support. | ||
| + | |||
| + | Current join support is limited to left outer join type only. This means that the result consists of all feature records from the primary source, even if the attributes are null. An inner join is defined as a join that results in only the records with matching secondary records. | ||
| + | |||
| + | A chained join is one in which the secondary source for a previously defined joined is used as a primary source for another join. This situation occurs when there is a need to join a secondary table to another secondary table, not just hang all secondary tables off the primary one. | ||
| + | |||
| + | It is possible that a secondary source within a join might have multiple records that match one primary record. This is a 1 : many case. Current functionality limits the joined records to only the first one, effectively enforcing a 1 : 1 case, such that the additional matching records are not available in the join result. By supporting the 1 : many case, all the joined secondary data is available for further analysis. | ||
=Motivation= | =Motivation= | ||
Revision as of 08:26, 3 November 2006
This page contains an change request (RFC) for MapGuide Open Source. More MapGuide RFCs can be found on the MapGuide RFCs page.
Status
- Submission Date: November 2, 2006
- Last Modified Date: November 2, 2006
- Author: Ronnie Louie
- RFC Status: draft
- Implementation Status: pending
- Voting History:
- Assigned PSC guide(s):
Overview
This proposal is to support additional functionality to feature source joins for chained joins, inner joins, and 1-to-many support.
Current join support is limited to left outer join type only. This means that the result consists of all feature records from the primary source, even if the attributes are null. An inner join is defined as a join that results in only the records with matching secondary records.
A chained join is one in which the secondary source for a previously defined joined is used as a primary source for another join. This situation occurs when there is a need to join a secondary table to another secondary table, not just hang all secondary tables off the primary one.
It is possible that a secondary source within a join might have multiple records that match one primary record. This is a 1 : many case. Current functionality limits the joined records to only the first one, effectively enforcing a 1 : 1 case, such that the additional matching records are not available in the join result. By supporting the 1 : many case, all the joined secondary data is available for further analysis.
Motivation
Current join support is limited to left outer join type only. This means that the result consists of all feature records from the primary source, even if the attributes are null. An inner join is defined as a join that results in only the records with matching secondary records.
A chained join is one in which the secondary source for a previously defined joined is used as a primary source for another join. This situation occurs when there is a need to join a secondary table to another secondary table, not just hang all secondary tables off the primary one. For example, “parcels” are joined to a secondary table of “owners”. But you want to join “owners” to “demographics” to do an analysis on age or income levels or family size.
It is possible that a secondary source within a join might have multiple records that match one primary record. This is a 1 : many case. Current functionality limits the joined records to only the first one, effectively enforcing a 1 : 1 case, such that the additional matching records are not available in the join result. By supporting the 1 : many case, all the joined secondary data is available for further analysis.
Funding/Resources
The effort to implement the proposed changes will be sponsored by Autodesk.
Proposed Changes
Chained joins will be specified using the name of a primary join as a prefix in the FeatureClassProperty attribute value using the following notation: <Primary_Join_name.Attribute_name>, where the dot symbol "." is used as a delimiter.
The notation for extended properties will use a delimiter to separate property names from their qualifiers in joins. The default symbol will be a vertical bar "|". This delimiter is a customizable string and is not limited to a single character.
Enhanced join support will make use of schema changes already incorporated into Bond for specifying the join type, 1 : many support, and the delimiter symbol for identifying extended attributes.
More details TBD.
Implications
These changes will impact existing join functionality. Existing applications will need to be updated for the new delimited extended property names. Older feature sources may need to be updated/migrated to the new schema. Documentation for will need to be updated for the new join functionality.
Test Plan
In addition to the existing tests for left outer joins, new test cases for inner join, chained joins, and 1 : many support will need to be created. These tests should cover joins to file-based sources as well as connection-based sources.