Extending table to add new columns failed

Development
1

Hello,

I have a task of extending the cohort_member table in core within my particular module. I was going through the wiki page trying to understand how to go about it. I believe I have most of the code in place, but I can’t wrap my head around how to seamlessly integrate the new columns in cohort_member table, since the table is basically a set that is used in the Cohort model?!

Here is the link to the github repo GitHub - vshl/openmrs-module-expandedcohort

Right now, I cannot view the Cohorts in the Cohort builder, here is the error message:

Log at 2016-07-09 18.20.12.txt (13.1 KB)

Feel free to ask me further questions. Any help is appreciated.

2

We generally do not recommend modifying core platform tables from modules. You can have the module create its own tables whose names are prefixed with the moduleId. Or you could create a pull request to the core platform with the table modification changes.

The error message you are getting simply means that your database table does not have the “start_date” column.

https://wiki.openmrs.org/display/docs/Extending+a+Table+Through+a+Module

3

Hi Daniel,

To give little more context, I am following the design directions as mentioned in the following forum. And after some discussion with Darius in this thread, we concluded that I will concentrate my efforts in a module owing to the time constraints and other factors pertaining to the nature of my project.

Do you think, I can achieve the same by duplicating the cohort_member table within my module and at the same time not break functionality with existing cohorts?

Thanks for the reply,

Vishal

4

You either need to make the changes to core (via PR) or extend the core table(s) in your module. Extending a core table (e.g., adding start and stop date to a cohort member) would typically be done with something like:

create table expandedcohort_cohort_member
  (
    cohort_member_id int PRIMARY KEY,
    start_date datetime,
    stop_date datetime,
    FOREIGN KEY (cohort_member_id) REFERENCES cohort_member (cohort_member_id)
  )

Unfortunately, cohort_member in core was not designed to persist member entries, so does not have it’s own primary key (it only has cohort_id and patient_id). Since rows in cohort_member are purged as members are removed and there’s no cohort_member_id primary key, you can’t extend the core cohort members in your module as Darius suggested. :confounded:

This really needs to be done in core. The only way to add start & stop dates to cohort members via a module would be to alter the core table (adding a cohort_member_id primary key along with start & stop dates) as well as changing core’s behavior with cohort members (currently purging members that are removed). You’ll probably spend more time trying to do this in a module than you would making the changes to core.

5

As I mentioned multiple times on the other thread, I recommend that you make these changes in (a feature branch of) openmrs-core.

Because that way you’re less likely to run into other dependencies and complexities, like this one.

6

Thanks Darius and Burke. After discussing with my peer group. I’ll try to make the changes in the core itself. Are there some development guidelines that I need to follow to bring forth the change within core?

7

If you haven’t already, review the GitHub Code of Conduct and Coding Conventions. In general, it goes something like this:

  • Fork openmrs-core
  • Make a branch (usually named after the ticket)
  • Get feedback from other devs as need via IRC or Telegram.
  • When ready, submit a PR
  • After it is approved, squash your commits into one commit (if multiple commits)
1 Like
8

Thanks Burke. That’s been useful. Do I have to create the associated ticket in JIRA? I will be forking the openmrs-core repo to my github and will create a feature branch.

9

@vshankar, sure, go ahead and create a ticket in the “OpenMRS Core” project in JIRA, and share a link to it here. (Someone will mark it ready-for-work and you can claim it.)

In this case I would name the branch something more descriptive, like “expanded-cohort”, but using the ticket number is okay too.

10

@vshankar even better is to name the branch TicketNumber-expanded-cohort (that way you have the best of both worlds)

11

Sorry it took long, I had some permission issue before I could create an issue. Here is the newly created ticket https://issues.openmrs.org/browse/TRUNK-4906.

12

@vshankar I marked the ticket as ready-for-work, so you can now go “claim” it.

13

Thanks for the help, Darius. Much appreciated.

14

@burke @darius I’ve been reviewing the openmrs-core code, and I hope the instructions to extend cohort_member table in the Design Forum still stand?

I am trying to gather the requirements to add the additional columns for cohort_member. I have added the additional columns in liquibase and removed the Unique constraint. Now the tricky portion of cohort_member being a collection mapping to Cohort, how does the additional columns (start_date, end_date) fit in within this mapping? Do we keep the mapping as it is or will this change?

Also, the two methods Cohort.getMembers(Date asOfDate) and Cohort.getMemberChanges(Date fromDate, Date toDate): will these two methods just be SQL query calls to return the list of Cohorts?

Thanks.

15

@vshankar did you get answered on this thread? Review of extending cohort_member table with new columns

16

Yes, I did. Thanks. I’m currently working on it.