Versions Compared

Old Version 18

changes.mady.by.user Ivo Ulrich

Saved on

compared with

New Version Current

changes.mady.by.user Sibendire Joshua

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The OpenMRS community has established a set of conventions regarding code style, format and more which aims at keeping the OpenMRS code consistent and in good shape. Refer to the following pages for more details

...

Code Repositories and Conventions

We use the Git for version control and GitHub for to host our Code Repositories now. See Using Git and you can watch a video of

Git

To read about how to use Git properly here

Branches

Commit Comments

Code Review

refer to: Using Git 

If you like watching a video try this one here

GitHub

If you want to contribute code you should read: GitHub Conventions

Code Review

If you want to help out in reviewing code this should help: Code Review

Backporting Code

When bug fixes and/or features are applied to earlier versions of the system, this is called "backporting."  OpenMRS uses major.minor.maintenance versioning (e.g., 1.7.3).  Maintenance releases are specifically designed to allow for bug fixes to be backported.  Sometimes features (not just bug fixes) are applied to previous releases.

...

  • We've chosen to use all lowercase names with underscores (_) between words (e.g., patient_address)
  • Use the singular form (e.g. patient_address instead of patient_addresses) except where the singular form is a reserved word (e.g. users instead of user, since user is a ?SQL Reserved Word)
  • Where auditing of rows is needed, use the following attributes:
    1. creator (FK to users)
    2. date_created (datetime)
    3. changed_by (FK to users)
    4. date_changed (datetime)
    5. voided (boolean)
    6. voided_by (FK to users)
    7. date_voided (datetime)
    8. void_reason (varchar 255)

...

  • Do not use int(11) (The display width in bracket is MySQL-specific and not useful), instead use int only
  • Use type="BOOLEAN" and defaultValueBoolean="<true|false>" instead of smallint, tinyint for boolean columns (Look out for voided, retired etc properties)
  • Use DOUBLE PRECISION instead of DOUBLE 
  • Use dbms="<databasetypename>" when creating database-specific SQL or changeset
  • Until 1.9 it is safe to assume that everyone was using MySQL-only, after that all liquibase changesets/database scripts should be database-independent

  • Following should be added for generating uuid in Microsoft SQL server:

    Code Block
    <modifySql dbms="mssql">
    <replace replace="CHAR(38)" with="UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID()" />
</modifySql>


  • autoIncrement="true" in liquibase will create a sequence in postgres with name <tableName>_<columnName>_seq. Use this to manipulate sequences during bulk inserts using the following:

    Code Block
    <modifySql dbms="postgresql">
    <prepend value="SELECT setval('encounter_role_encounter_role_id_seq', (SELECT MAX(encounter_role_id) FROM encounter_role)+1);"/>
</modifySql>


  • Instead of <modifyColumn> tag, use the more specific tags in liquibase 2.0 for column operations. e.g. <modifyDataType>
  • Always include a precondition for each changeset. Although liquibase does have a mechanism for applying only missing changesets, it is not always possible to rely on said mechanism due to maintenance workflows or historical reasons.
    • Some basic rules for preconditions:
      1. When adding a new table, column or foreign key constraint, the precondition should check that none already exists with the same name
      2. When adding a new table, it is recommended to add the foreign key constraints within the same changeset.
      3. When dropping a table, column or foreign key constraint, the precondition should check that one actually exists with the same name
      4. When renaming a table or column, the precondition should check that none exists with the new name and that there is one that already exists with the old name
    • If the precondition fails (for example, new table already exists), mark the changeset as already ran (attribute onFail="MARK_RAN")
  • Also document the changeset with a short comment
  • The ids of changesets should typically be time stamps of the format YYYYMMDD-HHSS or YYYYMMDD-HH:SS e.g 20140716-1415  or 20140716-14:15 respectively. You can optionally append the ticket number e.g 20140716-1415-TRUNK-4402. For modules, it is recommended to prepend the moduleId to the id of the changeset so that it is guaranteed to differ from those in core or other modules e.g calculation-20140716-1415 where calculation is the moduleId

...