Changes between Version 2 and Version 3 of MapGuideRfc123
- Timestamp:
- Oct 25, 2011, 7:10:43 AM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc123
v2 v3 74 74 75 75 {{{ 76 primary _[PrimaryClassName].[PropertyName] AS [PropertyName]76 primary.[PropertyName] AS [PropertyName] 77 77 }}} 78 78 79 primary _PrimaryClassNamewill be specified as the alias for the FdoIExtendedSelect::SetAlias() method79 primary will be specified as the alias for the FdoIExtendedSelect::SetAlias() method 80 80 81 81 Properties from the secondary class will be specified as the following FDO computed property: 82 82 83 83 {{{ 84 secondary _[SecondaryClassName].[PropertyName] AS [Prefix][PropertyName]84 secondary.[PropertyName] AS [Prefix][PropertyName] 85 85 }}} 86 86 87 secondary _SecondaryClassNamewill be used as the alias for the join criteria that is added to the FdoIExtendedSelect's join criteria collection.87 secondary will be used as the alias for the join criteria that is added to the FdoIExtendedSelect's join criteria collection. 88 88 89 89 Because the Extended Class Definition in a feature source does not explicity specify the list of properties from the secondary class to include, we include '''all properties''' from any secondary class that we are joining on by default. … … 105 105 Iteration logic for the normal case (not 1:1), is simply to pass over to the underlying reader's ReadNext() method. Tracking of identity property values is not required for this case. 106 106 107 Though not reflective of what the final implementation may be performance-wise, support for FDO joins has already been implemented in [http://mg-desktop.googlecode.com mg-desktop] and the benefits there are clear. The performance times for a 17000 feature by 16000 feature join (of [http://code.google.com/p/mg-desktop/source/browse/DesktopTestData/ParcelsJoinTest.sqlite this dataset]) are outlined below.107 Performance-wise, support for FDO joins has already been implemented in [http://mg-desktop.googlecode.com mg-desktop] and the benefits there are clear. The performance times for a 17000 feature by 16000 feature join (of [http://code.google.com/p/mg-desktop/source/browse/DesktopTestData/ParcelsJoinTest.sqlite this dataset]) are outlined below. 108 108 109 109 || Test Case || SDF || SQLite || … … 113 113 || Left Outer Join (1:1) || 320.9s || 4.6s || 114 114 115 As can be seen from this table, FDO joins performed on average, '''100 times''' faster than the traditional feature join counterpart! The SQLite provider implements the FDO join APIs. The SDF provider does not and is delegated to the GwsQueryEngine. 115 116 116 The SQLite provider implements the FDO join APIs. The SDF provider does not and is delegated to the GwsQueryEngine 117 118 We don't expect the same numbers in MapGuide due to server/web tier overhead, but this should give a clear indication of the orders of magnitude in performance gains if this RFC is implemented. 117 In the current implementation for the MapGuide Server, the SQLite numbers are even faster due to connection pooling and other caching mechanisms that are absent from the mg-desktop implementation. 119 118 120 119 === Aggregates ===
