undefined method `[]' for nil:NilClass. in import_daily
undefined method `[]' for nil:NilClass. in import_daily
could not connect to www.swissreg.ch: #<Net::HTTPInternalServerError:0x007f8a7d69bb58>
---
Got the following mail
We see that you own an active API key for the Flickr API, and wanted make sure you know about some upcoming changes to the API related to SSL.
As you may have read on the Flickr code blog, we've updated all of the API endpoints to fully support SSL. You no longer need to use a special subdomain to access the API securely, and we want to make sure that all API communication adopts SSL.
Many of you have moved over to using SSL already, which is great! If you haven't, it shouldn't be much more work than updating your apps to call the API at: https://api.flickr.com/
We'll be updating the blog with information as we get close to the switchover date, but here's the most important info:
New API keys will be issued for HTTPS access only: as of 6 May 2014
First blackout test window: 3 June 2014, 10:00-12:00 Pacific Daylight Time (PDT)
Second blackout test window: 17 June 2014, 18:00-20:00 (PDT)
Non-SSL API deprecated: 27 June 2014, 10:00 (PDT)
During the blackout tests and after the 27th of June, calls to the Flickr API that are not over SSL will fail with an HTTP error code 403. We will also return an error message with (Flickr) code 95 and msg "SSL is required".
Here are example error responses:
XML (REST):
<?xml version="1.0" encoding="utf-8" ?> <rsp stat="fail"> <err code="95" msg="SSL is required" /> </rsp>
JSONP:
jsonFlickrApi({ "stat": "fail", "code": "95", "message": "SSL is required" })
JSON:
{ "stat": "fail", "code": "95", "message": "SSL is required" }
We realize that this change might be more difficult for some. We will follow the Developer Support Group closely, so please let us hear your questions.
If you have a question about the API transition to SSL that you feel is unique to your situation or is more appropriate to handle via conversation directly with Flickr, send an email to flickr-api-help@yahoo-inc.com. We will monitor that mailbox through July 2014.
Thank you for being a member of our API community,
The Flickreenos
Looking at http://oddb-ci2.dyndns.org/de/gcc/fachinfo/reg/32710 we see a link to to Ponstan which uses http://www.flickr.com/photos/zrr/7628756076/in/set-72157630401120512.
An access to
http://www.flickr.com/photos/zrr/7628801974/in/set-72157630401120512/
gets redirected to https://www.flickr.com/photos/zrr/7628801974/in/set-72157630401120512/
bin/admin says
registration('00635').name_base
-> Luivac
registration('00635').packages.first.photo_link
-> http://www.flickr.com/photos/zrr/7628801974/in/set-72157630401120512/
ch.oddb> registration('32710').name_base
-> Ponstan
ch.oddb> registration('32710').fachinfo.photos.size
-> 4
ch.oddb> registration('32710').fachinfo.photos.first
-> {:name=>"Ponstan", :url=>"http://www.flickr.com/photos/zrr/7628756076/in/set-72157630401120512", :link=>true, :src=>"http://farm9.staticflickr.com/8168/7628756076_541049b8ce_t.jpg"}
We need to rename all these URL to https. But where did they get their values from? Will continue tomorrow.
Epha recently changed the location and format of its CSV-file. We adapted correctly to the new location.
But as in oddb2xml we must now split the lines correctly. As in oddb2xml we will use the CSV.parse_line function. Before being able to test it, I must wait for import_daily to finish.
Pushed commit Adapt to new CSV format of epha-interactions
We got the following error
Error: NoMethodError Message: undefined method `formats' for (image):ODDB::Text::ImageLink Backtrace: (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:173:in `block (2 levels) in format_line' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:166:in `each' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:166:in `block in format_line' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:161:in `each' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:161:in `format_line' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:139:in `block (2 levels) in lines' (druby://localhost:10005) /var/www/oddb.org/src/model/fachinfo.rb:206:in `call' (druby://localhost:10005) /var/www/oddb.org/src/model/fachinfo.rb:206:in `block in each_chapter' (druby://localhost:10005) /var/www/oddb.org/src/model/fachinfo.rb:204:in `each' (druby://localhost:10005) /var/www/oddb.org/src/model/fachinfo.rb:204:in `each_chapter' (druby://localhost:10005) /usr/local/lib/ruby/gems/1.9.1/gems/odba-1.1.0/lib/odba/stub.rb:112:in `method_missing' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:138:in `block in lines' (druby://localhost:10005) /usr/local/lib/ruby/gems/1.9.1/gems/odba-1.1.0/lib/odba/stub.rb:112:in `each' (druby://localhost:10005) /usr/local/lib/ruby/gems/1.9.1/gems/odba-1.1.0/lib/odba/stub.rb:112:in `method_missing' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/oddbdat.rb:136:in `lines' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/odba_exporter.rb:190:in `block (2 levels) in export_oddbdat' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/odba_exporter.rb:189:in `each' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/odba_exporter.rb:189:in `block in export_oddbdat' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/odba_exporter.rb:187:in `each' (druby://localhost:10005) /var/www/oddb.org/ext/export/src/odba_exporter.rb:187:in `export_oddbdat' (druby://localhost:10005) /usr/local/lib/ruby/1.9.1/drb/drb.rb:1548:in `perform_without_block' (druby://localhost:10005) /usr/local/lib/ruby/1.9.1/drb/drb.rb:1508:in `perform' (druby://localhost:10005) /usr/local/lib/ruby/1.9.1/drb/drb.rb:1586:in `block (2 levels) in main_loop' (druby://localhost:10005) /usr/local/lib/ruby/1.9.1/drb/drb.rb:1582:in `loop' (druby://localhost:10005) /usr/local/lib/ruby/1.9.1/drb/drb.rb:1582:in `block in main_loop' /var/www/oddb.org/src/plugin/oddbdat_export.rb:144:in `export_fachinfos' /var/www/oddb.org/src/util/exporter.rb:196:in `block in export_oddbdat' /var/www/oddb.org/src/util/exporter.rb:425:in `call' /var/www/oddb.org/src/util/exporter.rb:425:in `safe_export' /var/www/oddb.org/src/util/exporter.rb:192:in `export_oddbdat' /var/www/oddb.org/src/util/exporter.rb:67:in `block in run' /var/www/oddb.org/src/util/schedule.rb:15:in `call' /var/www/oddb.org/src/util/schedule.rb:15:in `run_on_weekday' /var/www/oddb.org/src/util/exporter.rb:63:in `run' jobs/export_daily:13:in `block in <module:Util>' /var/www/oddb.org/src/util/job.rb:40:in `call' /var/www/oddb.org/src/util/job.rb:40:in `run' jobs/export_daily:12:in `<module:Util>' jobs/export_daily:11:in `<module:ODDB>' jobs/export_daily:10:in `<main>'
I think I found the culprit and fixed it locally. Running jobs/export_oddbdat on oddb-ci2. It failed, because I had not restarted all daemons. Must run it again.
We got the following error
Plugin: ODDB::CoMarketingPlugin Error: Ole::Storage::FormatError Message: OLE2 signature is invalid Backtrace: /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:378:in `validate!' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:370:in `initialize' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:112:in `new' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:112:in `load' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:79:in `initialize' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:85:in `new' /usr/local/lib/ruby/gems/1.9.1/gems/ruby-ole-1.2.11.7/lib/ole/storage/base.rb:85:in `open' /usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.9.6/lib/spreadsheet/excel/reader.rb:1276:in `setup' /usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.9.6/lib/spreadsheet/excel/reader.rb:134:in `read' /usr/local/lib/ruby/gems/1.9.1/gems/spreadsheet-0.9.6/lib/spreadsheet/excel/workbook.rb:32:in `open' /usr/local/lib/ruby/gems/1.9.1/gems/swissmedic-diff-0.1.7/lib/compatibility.rb:13:in `open' /usr/local/lib/ruby/gems/1.9.1/gems/swissmedic-diff-0.1.7/lib/compatibility.rb:19:in `open' /var/www/oddb.org/src/plugin/comarketing.rb:86:in `get_pairs' /var/www/oddb.org/src/plugin/comarketing.rb:108:in `update' /var/www/oddb.org/src/util/updater.rb:510:in `update_immediate' /var/www/oddb.org/src/util/updater.rb:274:in `update_comarketing' /var/www/oddb.org/src/util/updater.rb:410:in `update_swissmedic_followers' /var/www/oddb.org/src/util/updater.rb:198:in `run' jobs/import_daily:13:in `block in <module:Util>' /var/www/oddb.org/src/util/job.rb:40:in `call' /var/www/oddb.org/src/util/job.rb:40:in `run' jobs/import_daily:12:in `<module:Util>' jobs/import_daily:11:in `<module:ODDB>' jobs/import_daily:10:in `<main>'
Adding a new testcase to test/test_plugin/comarketing.rb which is reading a small CoMarketing.xlsx. Can now reproduce the error.
Fixed the problem by changing from spreadsheet -> rubyXL. Now running jobs/import_swissmedic_followers completed.
Found 607 Co-Marketing-Pairs of which 574 were found in the Database New Connections: 4 Deleted Connections: 16 The following 33 Original/Comarketing-Pairs were not found in the Database: 36130 -> 45454 38683 -> 62769 45010 -> 58725 45011 -> 58727 46637 -> 52216 47469 -> 55492 47470 -> 56374 48342 -> 52768 48808 -> 52769 49786 -> 59283 50496 -> 60082 52036 -> 54709 52249 -> 57988 52249 -> 58905 52249 -> 63117 54378 -> 62757 55001 -> 59778 55065 -> 62748 55424 -> 48648 55424 -> 54808 55424 -> 55002 55425 -> 54376 55453 -> 61061 55585 -> 63064 55585 -> 63067 55977 -> 61891 57207 -> 65134 59031 -> 61661 59272 -> 62290 62128 -> 63066 62128 -> 63069 62471 -> 63065 62471 -> 63068
I cannot find 63066 -> Ropegra 135 mcg/0,5 ml, Fertigpen in under https://www.swissmedic.ch.
Pushed commit CoMarketing is now an xlsx-file, too. Added unit-test
undefined method `[]' for nil:NilClass. in import_dailyWe got the following error
Plugin: ODDB::SwissmedicPlugin Error: NoMethodError Message: undefined method `[]' for nil:NilClass Backtrace: /usr/local/lib/ruby/gems/1.9.1/gems/swissmedic-diff-0.1.7/lib/swissmedic-diff.rb:57:in `cell' /var/www/oddb.org/src/plugin/swissmedic.rb:139:in `cell' /var/www/oddb.org/src/plugin/swissmedic.rb:347:in `pointer_from_row' /var/www/oddb.org/src/plugin/swissmedic.rb:402:in `resolve_link' /var/www/oddb.org/src/plugin/swissmedic.rb:354:in `block in report' /var/www/oddb.org/src/plugin/swissmedic.rb:353:in `collect' /var/www/oddb.org/src/plugin/swissmedic.rb:353:in `report' /var/www/oddb.org/src/plugin/plugin.rb:54:in `block in log_info' /var/www/oddb.org/src/plugin/plugin.rb:53:in `each' /var/www/oddb.org/src/plugin/plugin.rb:53:in `inject' /var/www/oddb.org/src/plugin/plugin.rb:53:in `log_info' /var/www/oddb.org/src/util/updater.rb:146:in `log_info' /var/www/oddb.org/src/util/updater.rb:401:in `block in update_swissmedic' /var/www/oddb.org/src/util/updater.rb:500:in `call' /var/www/oddb.org/src/util/updater.rb:500:in `wrap_update' /var/www/oddb.org/src/util/updater.rb:396:in `update_swissmedic' /var/www/oddb.org/src/util/updater.rb:197:in `run' jobs/import_daily:13:in `block in <module:Util>' /var/www/oddb.org/src/util/job.rb:40:in `call' /var/www/oddb.org/src/util/job.rb:40:in `run' jobs/import_daily:12:in `<module:Util>' jobs/import_daily:11:in `<module:ODDB>' jobs/import_daily:10:in `<main>'
Looking at the log file log/oddb/debug/2014/05.log I found
2014-05-08 11:50:02 +0200: /var/www/oddb.org/src/plugin/text_info.rb:1355:in `block in import_swissmedicinfo_by_iksnrs': import_swissmedicinfo_by_iksnrs iksnr "62089" {}
2014-05-08 11:50:05 +0200: /var/www/oddb.org/src/plugin/text_info.rb:1355:in `block in import_swissmedicinfo_by_iksnrs': import_swissmedicinfo_by_iksnrs iksnr "65228" {}
2014-05-08 11:50:18 CEST @files={}
Taking a close look at 65228 "Metofol 5mg, Tabletten" was imported recently 2Datum des Datenimports : 03.04.2014. ch.oddb.org shows via /de/gcc/show/reg/65228 that it has a FI and a PI my oddb-ci2 (with an older database) shows only an FI.
Error occurs when the report is generated. The following bin/admin statement reproduces the error on oddb-ci2.
@atcless = @app.atcless_sequences.collect { |sequence| resolve_link(sequence.pointer) }.sort
@atcless = atcless_sequences.collect { |sequence| @tstSeq= sequence; resolve_link(sequence.pointer) }.sort; @tstSeq.iksnr
-> undefined method `resolve_link' for #<ODDB::App:0x007f038afd4208>
ch.oddb> @tstSeq.iksnr
-> 62686
Okay. We have a problem with iksnr 62686 and the method resolv_link which is defined in src/plugin/plugin.rb and src/plugin/swissmedic.rb.
src/plugin/plugin.rb contains a very bad piece of code which has hardcoded ch.oddb.org in it!
def resolve_link(model)
pointer = model.pointer
str = if(model.respond_to?(:name_base))
(model.name_base.to_s + ': ').ljust(50)
else
''
end
str << 'http://ch.oddb.org/de/gcc/resolve/pointer/' << CGI.escape(pointer.to_s) << ' '
rescue StandardError
"Error creating Link for #{pointer.inspect}"
end
Did this code ever get called from oddb-ci2?
We should probably replace all occurrences of ch.oddb.org by the value of SERVER_NAME from src/util/oddbconfig.rb.
Found a work-around and testing it running import_daily on oddb-ci2. Somehow it got stuck after emitting 2014-05-12 09:56:12 +0200: update_fachinfo Temesta®/- Expidet® iksnr 36203 store_fachinfo {}.
Pushed commit Avoid problem if resolve_link is undefined?
Willrerunn the import once I finished testing export_oddbdat.