0

An up coming project for a client involves using their MLS provider (which supports RETS) to list properties based on search criteria. I want to create a service (preferably in Java) which based on criteria inputted creates a single, or series of queries to make finding particular listing a little more intelligent then a direct translation to a query. (For example potentially searching for variations of a street name)

In research I've believe I've determined that in the past MLS data was gathered via periodic retrievals via ftp, but now RETS providers allow for a means to query for xml on a as needed bases. However a lot of the information I find seems to suggest that its commonplace to continue to sync with a provider periodically and maintain your own database from the information pulled.

This seems rather confusing to me, since why would you want to maintain the syncing of data between these two places, especially when one is a service you don't have control over?

What I would like to do is query for the rets provider per user request of information. And potentially insert entries directly to the service as well. Is this reasonable?

If not why not? (historical reasons or something I'm technically missing) and if so what would be a good starting point?

Please excuse my ignorance, I am an experienced applications developer and am used to dealing with databases and service APIs however I haven't developed any application using MLS or RETS before, and find the information I've googled rather confusing.

Mike McFarland
  • 657
  • 4
  • 17
  • Not sure what you mean by "create a service". I use RETSConnector to download the csv data feeds,then I wrote a C# program that generates SQL queries, and inserts the listings into a database. Then from the website, when a user searches for a property, it searches database and returns the results. – Andrew Briggs Mar 25 '12 at 19:01
  • What I meant was that I wished to pull information directly from the RETS provider through dmql queries on demand from the user, rather then querying a local database that's maintained by pulling from RETS periodically. This doesn't seem to be the norm, and after experiementation I can see that the RETS provider I'm working with is rather slow, and doesn't support a way of doing paging easily (no offset, and as part of the spec, no ordering in dmql) – Mike McFarland Aug 13 '12 at 19:00

1 Answers1

0

I ended up using RETSIQ to query the rets provider directly when users entered search criteria and return the results. This ended up functioning unacceptably slow, and didn't allow for paging because RETS built in doesn't allow any ordering. Eventually I ended up using RETSIQ to do a periodic pull and save locally in a database. RETs lack of ordering and particular providers not having some features (in my case offset) can make it hard to create the functionality you're looking for. I believe the reason why others also have choose to store their data locally is because you have more control over the speed performance, and choose persistence that allows you to retrieve the data the way you need to.

Its worth taking the time to see what features are supported from your provider, and whether you will need to page or sort results, and if you'll be able to accomplish it querying directly.

The answers probably not.

Mike McFarland
  • 657
  • 4
  • 17