HI @diana
Thank you for taking the time to get back to me.
The main concern is being able to hook into existing CHT functionality without having to maintain source file changes ourselves - which would also require a new image to be built.
Take the webapp/src/ts/services/xml-forms-context-utils.ts for example.
By having our date capture field named date_of_birth (instead of dob) we gain the ability to perform date calculation in the <app_form_name>.properties.json file - a feature we require for our new-born-child and pregnancy-and-womans-health forms.
I’m sure there’s a few other benefits with aligning our properties the way CHT caters for it, but at this time I’m not too well versed in all the functionalities provided the out of the box.
I’ve read that, and I’m speaking under correction, with non-relational databases one usually caters for these changes on the client side.
At this time though we’re not yet in full operation, but in a phase where we’re almost ready to go live - so we have explored this option as a possible solution to this issue and perhaps future scenarios.
It is with this in mind that I am attempting to keep the code base as clean as possible before more change requests come in - as I can imagine file complexity can increase quite significantly.
Especially since there’s a possibility that changes need to be made in multiple files for a change to take effect.
For instance changing dob → date_of_birth required a change in contact-summary.js, houehold-create (since we’re creating a person in there), the household_member-create and -edit files, and all the app forms that reference that value for certain calculations.
Writing a migration script would fix the problem by simply “renaming” all existing contact_type='hhm' records in the db and not require each of the files mentioned above to hold an additional reference to a dob field that may or may not apply anymore as time goes on - that will also need to be maintained.
Perhaps I’m not yet informed enough on how CHT uses the flexible structure, could you please provide an example?
The disruptions mentioned, do you perhaps have some more info on how impactful that may be?
At the moment the “solution” is the following file content placed in the “migrations” folder:
const { promisify } = require('util');
const db = require('../db');
module.exports = {
name: 'update-dob-in-hhm',
created: new Date(2023, 9, 13, 17, 6, 0, 0),
run: promisify(function(callback) {
db.medic.allDocs(
{ include_docs: true },
function(err, results) {
if (err) {
return callback(err);
}
console.log('************** RUN MIGRATION **************');
// console.log(results);
for (const key in results.rows) {
const entry = results.rows[key];
const doc = entry['doc'];
const contact_type = doc['contact_type'];
const hasDob = doc.hasOwnProperty('dob');
if(contact_type==='hhm' && hasDob){
doc['date_of_birth'] = doc['dob'];
delete doc.dob;
console.log(doc);
db.medic.put(doc);
console.log(`${doc['name']} migrated`);
}
else if(contact_type==='hhm'){ // Check if it was updated successfully
console.log(doc);
}
}
console.log('*****************************');
callback();
}
);
}),
};
Which gets executed by the following file:
const migration = require('./2023-09-13_dob_change.js');
console.log('Starting migration...');
migration.run((err) => {
if (err) {
console.error('Error running migration:', err);
} else {
console.log('Migration complete.');
}
});
console.log('Migration script execution finished.');
The last file gets triggered manually by running node <file_name>.js when testing locally.
With our current deployment environment though, we don’t have all the project files available.
Since these file relies on the ../db being present, it is providing some complexity.
Do you perhaps have an idea of how to approach this in a “flat” manner?