0

Well, I thought I'd finished!! I got the pset8 mashup map working - it does what it's supposed to, and the articles on the larger locations anyway are from google not onion, BUT...I just checked the staff version again and realised that my map works differently!! My markers are of obscure smaller places, not the larger ones and when I type in eg "New York", I get some outer New York postcodes, but none of the 10001 to 10009 codes that the staff version gives you when you type in New York. Likewise, when I test my search with the ...search?q=02138 test then it doesn't work. If I use a different postal code it does work, but not with 02138, but when I do a query on the SQL tab of the db with 02138, it gives the location details. So it's acting weird and it doesn't do the right things - but it pretty much does work. Can anyone help me - I don't want to submit it like this, because I don't think it's right, but have no idea where to start to work out why it's not working the same as the staff version.... my code is here (application.py): https://pastebin.com/GNY3TMN1 and here (scripts.js): https://pastebin.com/d94VuA3J and the mashup db seems to be as it should be and is in the mashup folder...thank you!

Improve this question
0

1 Answer 1

Reset to default
0

The difference in the "New York" results is probably this .....or admin_name1 like :q from search query. It is unlikely that staff version is matching on admin_name. Neither "/search?q=New+Jersey" nor "/search?q=Utah" returns any results. That particular select (New York) returns 2153 rows, and actually causes an overflow when sending the results back to the browser which is why the 10001-10009 postal codes don't show. (at least that's what firefox does, it gives this message SyntaxError: JSON.parse: expected ':' after property name in object at line 7916 column 16 of the JSON data).

/search?q=02138 worked perfectly when I tested this code. (BTW 02318 returns a big fat error, so maybe typo?) There is evidence (from this reddit post) that staff version does not use the same data as gets loaded from US.txt.

This pset gives the programmer a lot of latitude when it comes to results. I think it would be very difficult to match staff results exactly. If it wasn't, there would be a check50. IMO, submit it. You have the option to resubmit if you don't get a perfect score.

Improve this answer
3
  • 1
    Thank you DCS!!!!!! I think you have pretty much single handedly got me through this course and I'm very appreciative for all your help!! This reason is so simple I hadn't even considered it - and I think I'm going to take the admin_name off that query as the results are better without it - suddenly I'm getting many more google news results instead of the obscure postal codes that default to onion news - maybe this might help someone else in the same position some time! And very interesting that the staff version doesn't seem to use US.txt - that explains a lot!! :-/
    – CallyB
    Commented Apr 30, 2017 at 18:44
  • You're welcome, glad to help. Feels like finally putting my experience to good use :)
    – DinoCoderSaurus
    Commented May 1, 2017 at 2:07
  • :-) And I'm sure I'll be back with questions on my final project!
    – CallyB
    Commented May 3, 2017 at 9:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .