Rets::PropertyClient for retrieving rets properties and associated re…

[summera]

More work to do on this guy, but I wanted to get your thoughts before moving on. I have created something similar to this in my application and it has been really helpful to me, so hopefully it will be helpful to others! :smile:

The learning curve for querying RETS servers can be a little steep, and writing the code to retrieve resources can be a little cumbersome. The idea here is to make things a little easier. The basic idea is the following:

# holds some some simple configuration info based on some rets metadata
mls_config = SomeMlsConfiguration.new

property_client = Rets::PropertyClient.new(mls_config)

# retrieve properties modified within the last 24 hours
start_at = Time.now - (3600 * 24)
end_at = Time.now
properties = property_client.properties(start_at: start_at, end_at: end_at)

properties.each do |prop|
  # retrieve images for this property
  images = prop.images

  # retrieve open houses for this property
  open_houses = prop.open_houses
end

Let me know your thoughts!

[summera]

@dougcole @hfaulds Just checking back in on this. Thoughts?

[dougcole]

I like this idea a lot, we do something similar inside our closed source code at Estately, but I'm a little wary of adding it directly to the RETS gem. Currently the RETS gem is pretty small and focused on being a simple wrapper for the RETS specification in Ruby. Maybe this could be the start of a new project that builds upon the RETS gem?

I'm going to leave this open to get feedback from other people, these are just my initial thoughts...

[tdtran]

I like the code snippet a lot. It would be awesome! In certain sense we are attempting to bridge the RETS resource model and the object model, not unlike what ActiveRecord tries to do with SQL.

My concerns:

For property images property.images probably will work. In RETS images are Object which are tied to property via property system id and each property normally has some images. Image size is in tens of KBs (at least). The cost of establishing network connection is small compared to the transfer time.

The situation is different for open houses. We may have tens of thousand of properties but only a few hundeds open houses. If we have to iterate over each property to fetch open houses, for most properties we get empty list. It's much more network efficient to fetch all open houses then associate them with properties on our side even at the cost of throwing some open houses away (no matching properties, open houses scheduled for past dates, etc). This is similar to fighting SQL N+1 problem.

To complicate thing RETS does not have well defined method for associating open houses to properties. Open houses are resource, just like properties. The "primary/foreign key" used to associate them can be anything. In most cases it's RETS property system id but in many cases it's listing number (MLnumber, ListingNumber, ListingNo,..). We even ran into one case when the key is compound (TABLENAME + TABLEUID where TABLENAME in fact means property RETS class).

[summera]

@tdtran Great!

And thanks for this feedback! I have integrated with several RETs servers but am always surprised by something new, so your guys' experience and feedback will be a great help.

For property images property.images probably will work. In RETS images are Object which are tied to property via property system id and each property normally has some images. Image size is in tens of KBs (at least). The cost of establishing network connection is small compared to the transfer time.

Agreed on the images. I have some more ideas for handling images as well if we move forward with this.

The situation is different for open houses. We may have tens of thousand of properties but only a few hundeds open houses. If we have to iterate over each property to fetch open houses, for most properties we get empty list. It's much more network efficient to fetch all open houses then associate them with properties on our side even at the cost of throwing some open houses away (no matching properties, open houses scheduled for past dates, etc). This is similar to fighting SQL N+1 problem.

Agreed on open houses as well. This method is simply allowing you to grab the open houses for a specific property if you choose to do so. My thought process here is not necessarily to force anyone into a specific method of retrieving data, but just to make it easier for whichever way you choose. In our code, for most RETs servers, we make a request to retrieve open house data per property because that was the easiest thing to do at the time. Now, having more experience in the matter I totally agree with what you are saying. However, I don't think this is a reason to remove the method on the PropertyClienty. It is still useful. The code snippet is just a sample of what could be done. Maybe there is a potential to have an open house client to help with the retrieval of all open houses?

To complicate thing RETS does not have well defined method for associating open houses to properties. Open houses are resource, just like properties. The "primary/foreign key" used to associate them can be anything. In most cases it's RETS property system id but in many cases it's listing number (MLnumber, ListingNumber, ListingNo,..). We even ran into one case when the key is compound (TABLENAME + TABLEUID where TABLENAME in fact means property RETS class).

Haha. They don't like to make things easy! This is handled by the MlsConfiguration object. I haven't added the code to the PR yet but I have a plan of how to handle this. It may need to be adjusted based on your guys' experience. I have run into the case where the open house class is equal to the property class. My solution here was to have the MlsConfiguration#open_house_class method take the property class as an argument and output the open house class dynamically based on property class.

If you all are cool with this idea I'd be happy to move forward with it. I just wanted to get your thoughts before building out the entire thing. Let me know!

[tdtran]

@summera feel free to go ahead. I'd recommend to cleanly separate this functionality to a subpackage or something. Something like extension. Useful for users who have simple use cases but not a core feature set. We at Estately are unlikely to be the first to use it.

[tdtran]

and yes, we saw an MLS put open houses directly into property records too. Despite the fact that their RETS metadata advertises OpenHouse RETS resource. I myself wasted a couple of day chasing their open houses at the wrong place.

[dougcole]

Yeah, I think a separate package is the right place to start. We'd be happy to host it and/or link to it in the rets readme. I'm excited to see how this works out!

[summera]

A link in the README would be awesome. Thanks!! I'll add you guys as collaborators as well.

[dougcole]

Great, just let me know when the repo is up and I'll add a link to it in the readme.