140 | | The performance gain from using the new !GetSchemaNames, !GetClassNames, and !DescribeClasses command will be most notable for the RDBMS-based FDO providers. Support for the commands will be indicated by the provider's command capabilities object. Hence, only the RDBMS-based FDO providers will include !FdoCommandType_GetSchemaNames, !FdoCommandType_GetClassNames, and !FdoCommandType_DescribeClasses in the !GetCommands() response. Providers that do not support the new commands can fall back on using !DescribeSchema and walk through the results to retrieve the schema, class names, and class definitions. |
| 140 | The performance gain from using the new !GetSchemaNames, !GetClassNames, and !DescribeClasses command will be most notable for the RDBMS-based FDO providers. Support for the commands will be indicated by the provider's command capabilities object. Hence, only the RDBMS-based FDO providers will include !FdoCommandType_GetSchemaNames, !FdoCommandType_GetClassNames, and !FdoCommandType_DescribeClasses in the !GetCommands() response. |
| 142 | === Discussion of Alternate Approach (but not proposed as part of this RFC) === |
| 143 | |
| 144 | An alternative solution that does not create the new DesribeClasses command, is to modify DescribeSchema to allow the results to be filtered by class names, making it a fundamental part of the command. There would not be any capability exposed to advertise support for the new behaviour, so updating all providers becomes mandatory. Although this approach makes for a cleaner API experience in terms of DescribeSchema usage and consistency amongst all providers, there are some issues which makes the feasibility of this approach unsuitable at this time. |
| 145 | |
| 146 | 1. Not all providers would benefit from the new DescribeSchema. The main benefit would be the responsiveness of command for the RDBMS providers. Some of the file-based providers may also benefit, but if caching is used there may not be any significant improvement. As such, it would not be worth the effort to implement all providers when there is little to no gain. Solution to this should include optional implementation on an as-needed basis. |
| 147 | |
| 148 | 2. Updating the DescribeSchema command across all providers would need to be scheduled in a timely manner. Coordinating a mandatory command update with all provider writers (particulary from third parties) may pose significant challenges. |
| 149 | |
| 150 | 3. Resources for implementing in all providers is limited for all concerned parties. Since implementation of the DescribeSchema changes is not optional, this may create undue strain on available resources for all interested parties. |
| 151 | |
| 152 | By favouring optional implementation of the new DescribeClasses command over mandatory implmentation of changes to the existing DescribeSchema command, the effort can be focused on where it is needed most. It also allow flexibility for the other providers to determine if and when the command should be implemented based on their own criteria. |