Either that or get the media import to work with querying by rets key.
#Crmls matrix login manual
Along with that fix should be an option to set a batch size with the manual query.
First thing I'm going to try is using an identical server to see if same drealty update/delete performance issues arise.ītw, running the manual qurey seems to always hang on the last listing. We are using a dedicated server with centos 6.5, 32GB memory, 500GB SSD, Xeon processors, etc so the server should be able to handle these queries no problem-as it wasn't an issue in the past. Is it due to mysql 5.6 installation which is new and drealty queries may not be written optimized for this version. Is it due to something being wrong with the server (we did get hacked due to "Drupageddon" which was fixed) Is it due to having close to 300,000 properties
Is it phrets i did see an issue with memory leaks at github. Is it drealty 7.x-3.0-beta6 (since this wasn't an issue with last year's version) So now on my agenda is to figure out what exactly is causing this. after about 3000 it starts doing 1 deletion every 15+ seconds. after restarting mysqld, and doing drush -d rets-flush, the deletion starts out pretty quick, about 2-3 properties per second, then after about 1000 deletions, it starts to slow down. But one of the things I've noticed is that mysql database when doing large drealty queries, it comes to almost a crawl after doing several thousand updates or deletions-to the point where mysqld is showing 300% cpu usage. I haven't tested this on another server-so that may be an issue. This will return the media files for a particular listing, including images. To do this, you will need a ListingKey from a Property class and search against the ClassKey field in the Media class. Instead, you will need to query the Media class to retrieve images. If you need assistance in locating certain equivalent fields, please let us know and we can provide guidance.Īs for media/images, our RETS feed does not support the GetObject method. In transition over from the previous feed, you will need to make slight adjustments to your current queries to make it work with the new feed. In the new RETS feed, this is named ListingKey. For example, in the Property classes of the previous RETS feed, the Matrix_Unique_Identifier refered to the unique key. Notable ones are fields regarding unique values. There is about less than 10% to 15% where the field names may have change. Here is a reply from our new RETS provider tech support:įirst, in migrating over from to, a majority of the fields remain the same. MEDIA matrix_unique_id (String, 8 characters ) 79096741 = PROPERTY matrix_unique_id (String, 8 characters ) 79096741ĭrealty would need to allow an option to input a 'media key name' rather than try to draw an automatic association by looking for identical key names within 'property' and 'media' More details: This is our OLD RETS provider-where drealty images worked fine since the 'key names' for 'property' and 'media' are identical: Hence, drealty can't associate the 2 different 'key names' together. With our new RETS provider, the only ' key values' that DO match up between 'property' and 'media' are different ' key names'. MEDIA ClassKey (String, 7 characters ) 7568074 = PROPERTY ListingKey (String, 7 characters ) 7568074 MEDIA ClassSourceKey (String, 8 characters ) 79096741 = PROPERTY SourceKey (String, 8 characters ) 79096741 If the property and media key names are different then it can't associate these, hence no image option. if 'property key' = 'media key' THEN show image option. Explanation:ĭrealty is expecting the RETS provider to use the SAME key names for 'property' and 'media' so it can draw an association between the key values.Į.g.
However, this new one uses different key names for property and media, hence images option does not show. Now we were assigned a new one that only supports RETS 1.7.2 and 1.8. We've been using drealty successfully for 3 years now with our old RETS provider.
0 kommentar(er)
