Changes between Version 1 and Version 2 of MapGuideRfc5

Timestamp:

Feb 27, 2007, 6:29:11 PM (17 years ago)

Author:

waltweltonlair

Comment:

Just formatting fixes...

MapGuideRfc5

@@ -35 +35 @@
 The existing feature join functionality requires the feature source to define an extension to a primary feature class.  This extension is defined by identifying the secondary feature source and feature class, along with the attributes from both classes to join on.  The extension does not specify the type of join to perform, which actually is left outer join only.  There are situations where an inner join type on the data is desired, however this option is currently not possible since there is no way to choose a join type with the current implementation.  
 
-Joins in MapGuide currently consist of one primary feature class joined to one or more secondary feature classes.  The secondary class cannot be extended via join in MapGuide even though it may make sense to perform such a chained join.  For example, a primary table “parcels” is 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.  
+Joins in !MapGuide currently consist of one primary feature class joined to one or more secondary feature classes.  The secondary class cannot be extended via join in !MapGuide even though it may make sense to perform such a chained join.  For example, a primary table “parcels” is 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.  
 
-When a primary feature record is joined to secondary source, there may be one or more matching secondary records.  MapGuide is only retrieving the first matching secondary record and ignoring the rest.  Users would need to interrogate the secondary source separately to obtain the additional data.  This is cumbersome and possibly error prone as there is no indication provided that additional records may exist.  We need to provide an option to the extension definition to facilitate a 1 : many join result.  For example, a primary table "parcels" is joined to a secondary table of "owners".  A particular parcel "A01" is can have 3 different owners.  MapGuide currently implements the 1 : 1 case, and retrieves the first encountered owner and displays a single parcel geometry on the map.  The other two owners are never displayed in any fashion.  If MapGuide supports a 1 : many option, MapGuide will be able to provide the details for all three owners, should the need arise.
+When a primary feature record is joined to secondary source, there may be one or more matching secondary records.  !MapGuide is only retrieving the first matching secondary record and ignoring the rest.  Users would need to interrogate the secondary source separately to obtain the additional data.  This is cumbersome and possibly error prone as there is no indication provided that additional records may exist.  We need to provide an option to the extension definition to facilitate a 1 : many join result.  For example, a primary table "parcels" is joined to a secondary table of "owners".  A particular parcel "A01" is can have 3 different owners.  !MapGuide currently implements the 1 : 1 case, and retrieves the first encountered owner and displays a single parcel geometry on the map.  The other two owners are never displayed in any fashion.  If !MapGuide supports a 1 : many option, !MapGuide will be able to provide the details for all three owners, should the need arise.
 
 == Proposed Solution ==
@@ -52 +52 @@
 Changes to join notation is summarized as follows:
 
-1.  To support chained joins, notation needs to be introduced for defining these joins.  Particularly, the secondary attribute from a primary join needs to be specified as the primary join property for a chained join.  The primary join name and feature class property will use the dot symbol "." to separate the join name from the class property in the FeatureClassProperty attribute.  The FeatureClassProperty value will be prefixed by the primary name using the the following notation '''<Primary_Join_name.FeatureClassProperty_name>'''.
+1.  To support chained joins, notation needs to be introduced for defining these joins.  Particularly, the secondary attribute from a primary join needs to be specified as the primary join property for a chained join.  The primary join name and feature class property will use the dot symbol "." to separate the join name from the class property in the !FeatureClassProperty attribute.  The !FeatureClassProperty value will be prefixed by the primary name using the the following notation '''<Primary_Join_name.!FeatureClassProperty_name>'''.
 
-2.  As previously mentioned, extended properties will be identified by using a delimiter to separate the property names from their join qualifiers.  The current implementation, requires joins to be named, and that name is used to qualify the extended properties.  For example, the join between "parcels" and "owners" is given the name "ParcelOwnerJoin".  The "owners" table has attributes "Id" and "Name".  The join result contains "ParcelOwnerJoinId" and "ParcelOwnerJoinName" to indicate the "Id" and "Name" are extended attributes.  By introducing a delimiter, say a vertical bar "|", the extended properties will be "ParcelOwnerJoin|Id" and "ParcelOwnerJoin|Name".  This makes it clearer as to which attributes are in fact extended attributes.
+2.  As previously mentioned, extended properties will be identified by using a delimiter to separate the property names from their join qualifiers.  The current implementation, requires joins to be named, and that name is used to qualify the extended properties.  For example, the join between "parcels" and "owners" is given the name "!ParcelOwnerJoin".  The "owners" table has attributes "Id" and "Name".  The join result contains "!ParcelOwnerJoinId" and "!ParcelOwnerJoinName" to indicate the "Id" and "Name" are extended attributes.  By introducing a delimiter, say a vertical bar "|", the extended properties will be "!ParcelOwnerJoin|Id" and "!ParcelOwnerJoin|Name".  This makes it clearer as to which attributes are in fact extended attributes.