I don't know what the deal is, but I keep getting the following error doing 'drush -u admin -d rets-import'
Undefined index: MLnumber drealty.daemon.php:540 [5.42 sec, 54.57 MB] [notice]
Undefined index: Matrix_Unique_ID drealty.daemon.php:540 [5.42 sec, 54.57 MB] [notice]
Undefined index: Status drealty.daemon.php:540 [5.42 sec, 54.57 MB]
This scrolls on forever...
Notes:
- I was able to get version 7.x-2.0-beta18 to import data.
- with version 3.0, I tried switching out the MLnumber and Matrix_Unique_ID in 'Id Field' and 'key field'; i.e. doing all possible combinations and each time the same error message.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | drealty_undefined_fields.patch | 1.48 KB | twod |
| #6 | drealty-2.0-offset.jpg | 214.79 KB | duntuk |
| #6 | drealty-2.0-offset-data-import.jpg | 348.66 KB | duntuk |
| #2 | 2012-03-21_021044.jpg | 1.22 MB | duntuk |
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