|
|||||||||||||||
RETS Support Article
The solution is to maintain backward compatibility to the previous version in the metadata when RETS Server upgrades are made. Rapattoni Corporation can add new columns to the metadata as requested and coordinate between the customer and RETS client vendors. If you have any questions about this process, please feel free to contact Rapattoni's RETS Support by e-mail or by phone. In addition, some case studies are shown below. Examples 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 know how to handle the additional SystemNames should the Select argument not be utilized 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 and get that additional data. Case 2: SystemNames modified in the metadata When SystemNames have to be modified in the metadata due to schema changes in the underlying MLS database, Rapattoni's practice is to issue a notice of the upcoming change and perform the change on the first Wednesday of the month. 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. 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 Amenities, and so on can be modified in a dynamic way on the Internet MLS and those changes are migrated over to the RETS server. RETS clients need to check the metadata version after a successful Login transaction and see if any lookup values have been modified. The RETS Specification mandates that clients must check 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 lookup metadata from the host. |
| ||||||||||||||
|
|