view · edit · sidebar · attach · print · history

< Niklaus.20180214-lighthouse | Index | Niklaus.20180212-changelog-problem >>

20180213-doctor-Encoding-CompatibilityError

Summary

  • Refdata-Nat fix Error: Encoding::CompatibilityError
  • Cannot display patinfo for reg 55297 sequence 04 (Keppra)
  • oddb2xml shows Suliqua as inactive
  • Keep in Mind

Commits

Index

Refdata-Nat fix Error: Encoding::CompatibilityError

We have an Encoding::CompatibilityErro when running the refdata_nat import or visiting https://ch.oddb.org/de/gcc/search/zone/doctors/search_query/7601000064998?

Why do we have this difference. I am getting yesterday db dump and import it on oddb-ci2. My import completed without problem on oddb-ci2. But after importing the database dump from thinpower I have the same problem with given doctor gln.

Using pry I see

[1] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines 
=> ["Monsieur le Docteur", "Michel Vouilloz", "Cabinet médical", "Le Yucca", "1941 Cries (Voll\xC3\xA8ges)"]
[2] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines.to_s.encoding
=> #<Encoding:UTF-8>
[3] pry(#<ODDB::View::Doctors::DoctorList>)> (address.lines + emails).join("<br>") 
Encoding::CompatibilityError: incompatible character encodings: UTF-8 and US-ASCII
from (pry):3:in `join'
[9] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines[4]
=> "1941 Cries (Voll\xC3\xA8ges)"
[10] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines[4].encoding
=> #<Encoding:US-ASCII>
[11] pry(#<ODDB::View::Doctors::DoctorList>)> 
[12] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines[2].encoding
=> #<Encoding:UTF-8>
[13] pry(#<ODDB::View::Doctors::DoctorList>)> address.lines[2]
=> "Cabinet médical"

Therefore I think I will modify src/model/address.rb to always return UTF-8 encodings for all lines.

Added the following function in src/model/address.rb

        def to_utf(line)
          return unless line
          return line if line.encoding.to_s.eql?('UTF-8')
          if /ISO-8859-1/.match(line.encoding.to_s)
            line.encode!('UTF-8')
          else
            line = line.force_encoding('UTF-8')
          end
        end

And used in various places where non-utf-8 encodings were possible. Now displaying this doctor has no longer a problem.

Restarting the import of refdata_nat. Looks like the changes for utf-8 compatibility are okay for the import, too. Pushed commit Fix encoding problem in address

Starting import in screen on thinpower.

Fixed the unit tests with commits

Cannot display patinfo for reg 55297 sequence 04 (Keppra)

Visiting http://i.ch.oddb.org/de/mobile/patinfo/reg/55297/seq/04 gives the following error

NoMethodError at /de/mobile/patinfo/reg/55297/seq/04
undefined method `packages' for nil:NilClass
Ruby	/var/www/oddb.org/src/view/drugs/patinfo.rb: in change_log, line 145
Web	GET i.ch.oddb.org/de/mobile/patinfo/reg/55297/seq/04
Jump to:
GETPOSTCookiesENV
Traceback (innermost first)
/var/www/oddb.org/src/view/drugs/patinfo.rb: in change_log
54      ikscd ||= @session.app.registration(args[1]).sequence(args[3]).packages.keys.first ...
/var/www/oddb.org/vendor/ruby/2.5.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb: in create
					self.send(component, *args)...

We have here a problem, that the same patinfo belongs to several packages in more than one registrations/sequence.

Added a watir test for this problem. Pushed commit Fix wrong links when visiting PI chapters in second sequence of a registration

oddb2xml shows Suliqua as inactive

Looked at my local run of oddb2xml -e and found the mentioned 7680662830035 Suliqua 100/33, solution injectable the following entry, where the salecd is 'A'.

Downloaded https://download.hin.ch/download/oddb2xml/oddb_article.xml and found the same info (with a different timestamp of co

  <ART DT="2018-02-13 00:00:00 +0100" SHA256="2fb5cadf56a47a3eff54b0f2747ff763a75bd60c9e1b080cc76ac05271bc4e29">
    <REF_DATA>1</REF_DATA>
    <PHAR>7298959</PHAR>
    <SMCAT>B</SMCAT>
    <GEN_PRODUCTION>X</GEN_PRODUCTION>
    <SMNO>66283003</SMNO>
    <PRODNO>6628302</PRODNO>
    <VAT>2</VAT>
    <SALECD>A</SALECD>
    <CDBG>N</CDBG>
    <BG>N</BG>
    <DSCRD>SULIQUA 100/33 Inj Lös SoloStar Fertpen 3 Stk</DSCRD>
    <DSCRF>SULIQUA 100/33 sol inj SoloStar stylo pré 3 pce</DSCRF>
    <SORTD>SULIQUA 100/33 INJ LÖS SOLOSTAR FERTPEN 3 STK</SORTD>
    <SORTF>SULIQUA 100/33 SOL INJ SOLOSTAR STYLO PRÉ 3 PCE</SORTF>
    <SYN1D>Suliqua 100/33</SYN1D>
    <SYN1F>Suliqua 100/33</SYN1F>
    <SLOPLUS>2</SLOPLUS>
    <ARTCOMP>
      <COMPNO>7601001002340</COMPNO>
    </ARTCOMP>
    <ARTBAR>
      <CDTYP>E13</CDTYP>
      <BC>7680662830035</BC>
      <BCSTAT>A</BCSTAT>
    </ARTBAR>
    <ARTPRI>
      <VDAT>01.01.2018</VDAT>
      <PTYP>PEXF</PTYP>
      <PRICE>83.18</PRICE>
    </ARTPRI>
    <ARTPRI>
      <VDAT>01.01.2018</VDAT>
      <PTYP>PPUB</PTYP>
      <PRICE>111.9</PRICE>
    </ARTPRI>
    <ARTPRI>
      <PTYP>ZURROSE</PTYP>
      <PRICE>90.01</PRICE>
    </ARTPRI>
    <ARTPRI>
      <PTYP>ZURROSEPUB</PTYP>
      <PRICE>111.90</PRICE>
    </ARTPRI>
    <ARTINS>
      <NINCD>10</NINCD>
    </ART

It looks to me as either they didn't use the most recent oddb_arcticle.xml, or the import into the other database was not successfull.

Wondering why the travis-ci build for oddb2xml fails, but my local test is okay. Hope that commit Don't call exit(2) if xmllint is not present. Should fix travis-CI problem fixes this problem.

view · edit · sidebar · attach · print · history
Page last modified on February 14, 2018, at 08:10 AM