Title: |
Maintaining RETS Metadata |
Submitted by: |
Rapattoni RETS Support |
Updated: |
03/21/2011 |
Version: |
RETS 1.7.2 |
Issue: |
Rapattoni Corporation upgrades its Internet-based MLS system appoximately twice per quarter. When an upgrade occurs, RETS servers for those customers may also need to be upgraded to work with the new MLS database schema. If changes to the existing RETS metadata are made it might break existing RETS clients unless certain guidelines are established to handle these types of scenarios. These guidelines are the subject of this article. |
The solution is to maintain backward compatibility to the previous version in the metadata when RETS Server upgrades are made.
If you have any questions about this process, please feel free to contact Rapattoni's RETS Support by email or by phone. In addition, some case studies are shown below.
In addition, it is Rapattoni's practice to issue a monthly notice of the upcoming change and perform the change on the first Wednesday of the month. To view the notices that have been published by Rapattoni, click here.
Case 1: SystemNames added to the metadata
There shouldn't be any problem with new SystemNames added to the metadata. The only issue that may arise is that a client may not know how to handle the additional SystemName(s) returned in the server response should the Select argument be omitted in the Search transaction. If a RETS client does not specify specific SystemNames (in the order it wants them) for its queries and is instead relying on the default SystemNames returned for a Search to always be the same, then there could be a risk of breakage on the client side. However, if a RETS client always specifies the SystemNames (in the order it wants them) it wants returned in a query, there should be no problems for that client when metadata is upgraded.
Example: A RETS client specifies SystemNames A, B, and C in an ActiveAgent query in the Select argument. The METADATA-TABLE metadata is upgraded to a new version and now fields D, E, and F are available for ActiveAgent. The RETS client would still get back data for A, B, and C in an ActiveAgent query because it specified those SystemNames in the Select argument. If the RETS client wants to, it can add SystemNames D, E, and F to its Select argument to get that additional data.
Case 2: SystemNames modified in the metadata
SystemNames have to be modified in the metadata when there are schema changes in the underlying MLS database. In these scenarios it is highly recommended that the client update any process or backend data storage that might be impacted by the change.
Case 3: SystemNames removed from the metadata
This is the most serious case for metadata upgrades. If for some reason a change is made to the underlying MLS database schema where a field is dropped from the database and the data is no longer available, the SystemNames will be removed from the metadata. Such SystemNames will no longer be returned in Search transactions, regardless of whether the client does or does not utilize the Select argument. In these scenarios it is highly recommended that the client update any process or backend data storage that might be impacted by the deletion.
Case 4: Lookup values modified in the metadata
Lookup values can be modified in the metadata at anytime. Lookup values for SystemNames like City, Area, Subdivision, School Districts, Schools, Styles and so on can be modified in a dynamic way on the Internet MLS and those changes are migrated over to the RETS metadata. The RETS Specification recommends that clients check the metadata version upon logging into a RETS server. This is the minimum version of the metadata that the host will support. If the version of the metadata being used by the client is less than this version, the client MUST retrieve the latest metadata from the host.