Closed (fixed)
Project:
Drupal RETS Real Estate Framework (dRealty)
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
21 Mar 2012 at 09:01 UTC
Updated:
28 Jul 2012 at 07:15 UTC
Jump to comment: Most recent file
Comments
Comment #1
duntuk commentedhere's a full metadata listing:
note: 'MLS_ID' isn't the actual MLS # it's just the 'type' of MLS which has predefined values. I mistaken that initially. 'MLnumber' is the actual MLS #. 'Matrix_Unique_ID' is defined as a 'Key Field' .
Comment #2
duntuk commentedComment #3
duntuk commentedHmm... I figured out a solution.
Changed 'Query Type' to 'Offset Not Supported (Query based on RETS Key)' which imported data sucessfully.
However, in 2.0 version i was able to keep this at: 'Default (Server must support offset. Relies on RETS Status Field.)' and it worked fine.
I'm guessing this probably a bug.
Comment #4
camidoo commentedYea that is a bug. And you're 100% sure that your server supports offset, I'm assuming that it does as you said that you were able to import data before in the 2.x branch. I think i know what the problem might be.
Comment #5
camidoo commentedI'll take a look this morning.
Comment #6
duntuk commentedThanks! I'm able to import data on 7.x-2.0-beta18 using offset setting for sure.
I'm running 2 separate installations on different sites.
I've included the 2.0 offset import... (yeah, there is a geocode error, but all other data imports fine)
e.g.
Comment #7
camidoo commentedStill haven't had time to look at this yet, however it's on my list
Comment #8
camidoo commentedwere you ever able to get past this?
Comment #9
twodI get these "Undefined index" warnings on one server but not the other. Haven't looked closer at it but I think it happens because the returned XML is parsed into the
$rets_itemobject but empty XML elements/tags aren't added as empty/NULL values to the object.Anyway, this patch fixes the warnings for me.
Comment #10
jday commentedfeedback: I applied the patch manually to the beta3 version to see if it would keep empty fields from displaying, unfortunately, they are still displaying...
Comment #11
twodDo the should-be-empty fields happen to be numeric? If so, #1534508: Change the default numeric value to NULL should have fixed that.
However... Since that change didn't get in until beta3, any listing not updated/re-imported after you upgraded to beta3 may still be using a 0 instead of NULL in the database. Unless you flush and re-import everything, those 0s won't be changed to NULLs until the hash of the RETS fields for that listing changes.
The patch here will most likely not affect whether a field is considered empty or not because it only affects whether a field becomes NULL or undefined, which should both be similar enough to be considered empty. (Might be wrong tho.)
Comment #12
camidoo commentedcommitted
Comment #12.0
camidoo commentedadded note about error message