Null values in concept_view table for fully specified names given in different locale(other than English)

Tags: #<Tag:0x00007f0a2ad1fc00> #<Tag:0x00007f0a2ad1eeb8>

Hello everyone, Existing concept_view table has below concept details:

  • concept_id
  • concept_full_name
  • concept_short_name
  • concept_class_name
  • concept_datatype_name
  • description

We found that “concept_full_name” column is giving NULL values when we have Fully Specified Name given in locales other than English. Is this expected behaviour? Or should it contain all the values irrespective of locale? @angshuonline @praveenad @buvaneswariarun @mksrom @mksd @binduak

Thank you,

Hi @vineela,

concept_view table, where’s that? Is that Bahmni Mart-related?

Hi @mksd, I could see this concept_view table in openmrs database. That could be either from Bahmni or Openmrs but not from mart.

@samuel34 did you create that SQL query, how did you migrate it from somewhere else? See here.

The PR is here actually. @vineela you may want to dive into the PR and ticket to see if the conversations are giving clues as to where the original SQL query comes from and why it was designed the way it is.

Thanks @mksd, The ticket from the above PR is not very specific to concept_view creation. That ticket is for the whole liquibase.xml. But from the create sql here, I could see that we are choosing the concept full name only in english locale. May be at the time of creation of concept_view, we might have considered only English.
Going forward do we think we should give support for all the locales?
@mksd @mksrom @angshuonline @praveenad @buvaneswariarun

@Vineela, I have noticed too in many places the preferred locale is English. @buvaneswariarun & I are working on the Internationalisation of some of Bahmni modules (Registration and Clinical Dashboard). we are trying to address some of the locale concerns here but updating such findings like yours is not in our scope. In the future we can include localisation as one of the acceptance criteria for all new developments.

Yes of course, it is a design flaw of Bahmni to be ‘en’ centric. Improving its i18n is part of the tech debt that needs to be addressed on an ongoing basis.

The intent of the “view”, )its not a table) is towards ease of reporting. I am surprised that it found its usage in Bahmni-core. I think it ought to be in Bahmni-reports. I think @mksrom found it to be misplaced in another endTB specific migration and reliance of it in Bahmni-core. We should change that to move the migrations to Bahmni-reports only and also refactor some of the dependencies in bahmni-core, which i checked and think can be easily overcome with alternate means.