Page Comparison

...

Developing Code for OpenMRS

• Coding Java Conventions

Repository Conventions

We use Git and GitHub for our Code RepositoryRepositories now. See Using Git and you can watch a video of how to use Git properly here

...

• Git Branching and Merging Techniques
• (deprecated) Subversion Branching and Merging Techniques

Commit Comments

• GitHub Code of ConductConventions
• (deprecated) Subversion Code of Conduct

...

• 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 and a short comment 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. 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
  it
  2. 1. one actually
  one already
  3. 1. exists with the same name
     2. 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

...