I have checked in the inital version of the tribe module. (I think I changed the id in the .project file.) I will wait and see what my mentor, Ben has to say. There will be changes to make. Or may be completely redo it. I am going start the next project in a few days, may be the end of the week. I have some assignments to do.
Today I got the Google’s payment card. It is a MasterCard credit card in appearance with the name XXXX GSOC 2008 STUDENT.
Tribe module is ready to be checked in. I have attached the core OpenMRS system changes to the ticket. There is another update to the core system to allow registering module level FieldGenHandlers. I have written an SQL script to upgrade an existing implementation, by moving the patient tribe values to a person attribute type value as follows.
– disable auto commit
SET @currentAutoCommit = @@autocommit;
SET @@autocommit = 0;
START TRANSACTION;
– create the tribe person attribute type
INSERT INTO person_attribute_type
(name, description, format, creator, date_created)
VALUES (‘Tribe’, ‘Tribe of the person’, ‘org.openmrs.module.tribe.Tribe’, 1, NOW());
SET @tribeTypeId = LAST_INSERT_ID();
– insert person attributes for patient tribe values
INSERT INTO person_attribute (person_id, value, person_attribute_type_id, creator, date_created)
SELECT patient_id, tribe, @tribeTypeId, 1, now() FROM patient WHERE tribe IS NOT NULL;
– remove tribe column
ALTER TABLE patient DROP FOREIGN KEY belongs_to_tribe;
ALTER TABLE patient DROP COLUMN tribe;
– commit everything and restore auto commit value
COMMIT;
SET @@autocommit = @currentAutoCommit;
I wrote a MySQL stored procedure to upgrade the existing patient tribe values to a person attribute type. This method is not going to be used, so it will not be checked in. So I am putting it here so that somebody may get some use out of it.
– define the procedure
DELIMITER $$
DROP PROCEDURE IF EXISTS `openmrs`.`convert_tribe`$$
CREATE PROCEDURE `openmrs`.`convert_tribe` ()
BEGIN
DECLARE currentAutoCommit BOOLEAN;
DECLARE tribeTypeId INT(11); — tribe person attribute type id
– fetched values of patients with tribe are stored in the following variables
DECLARE patientId INT(11);
DECLARE tribeId INT(11);
DECLARE noMoreRows INT(11) DEFAULT 0;
DECLARE patientsWithTribe CURSOR FOR
SELECT patient_id, tribe FROM patient WHERE tribe IS NOT NULL;
DECLARE CONTINUE HANDLER FOR NOT FOUND
BEGIN
SET noMoreRows = 1;
END;
– disable auto commit
SELECT @@autocommit INTO currentAutoCommit;
SET autocommit = 0;
START TRANSACTION;
– create the tribe person attribute type
INSERT INTO person_attribute_type
(name, description, format, creator, date_created)
VALUES (‘Tribe’, ‘Tribe of the person’, ‘org.openmrs.module.tribe.Tribe’, 1, NOW());
– get the created tribe person attribute type id
SELECT person_attribute_type_id into tribeTypeId FROM person_attribute_type WHERE name = ‘Tribe’;
– read patient tribe values and add new person attributes
OPEN patientsWithTribe;
cursorLoop : LOOP
FETCH patientsWithTribe INTO patientId, tribeId;
IF noMoreRows = 1 THEN
LEAVE cursorLoop;
END IF;
INSERT INTO person_attribute (person_id, value, person_attribute_type_id, creator, date_created)
VALUES (patientId, tribeId, tribeTypeId, 1, now());
END LOOP cursorLoop;
CLOSE patientsWithTribe;
– remove tribe column
ALTER TABLE patient DROP FOREIGN KEY belongs_to_tribe;
ALTER TABLE patient DROP COLUMN tribe;
– commit everything and restore auto commit value
COMMIT;
SET autocommit = currentAutoCommit;
END$$
DELIMITER ;
– run the procedure
CALL convert_tribe;
– drop the procedure
DROP PROCEDURE convert_tribe;
Tonight I got a working FieldGenHandler for the tribe object. The registering of FieldGenHandlers through modules is working now. All the existing FieldGenHandler code exist in the core OpenMRS system. Because the tribe is inside a module, core system cannot have a dependency on the tribe module. Until midnight I could not think of a way to get the core system to work with the tribe objects. I was sleepy and was going to call it a day. But then I started the machine again and tried one last time. In around fifiteen minutes I got it working. I created a generic fieldgen code and added it to the core system and used it to show the tribe objects. All the risky parts of the project are now complete. What remains is creating the SQL to upgrade an existing implementation to use the new tribe module.
So far everything was going okay. Tonight I implemented the Attributable interface. Now I can add tribe as a person attribute using the manage person attribute types page in the OpenMRS administration. But I cannot add or edit values for tribe person attribute type. I checked the source to learn how location and other person attributes are doing it.
I have to add a FieldGenHandler for the tribe object to make it editable and to let the user add or make changes to the tribe field. But so far all the FieldGenHandlers are made for core OpenMRS objects. My mentor Ben provided a fix to register handlers outside the core system. For the last 3 days Ben has checked in code to fix some issues I faced within a few minutes after I asked, without which could not proceed with coding.
Tonight I assembled the tribe module and got it working. So far I have just extracted the code but did not try to run it. Tribe add, update and retire features are working okay. So far the tribe objects are working separately from the core OpenMRS system. The tribe module can create and update the tribe objects but the tribe objects have no interaction with the rest of the system.
Now what I have to do is transform the tribe object to a person attribute compatible object. I am using the existing Location object as the reference for the implementation. But tribe object is an entity that resides in an external module, while location is an object which exist inside the core OpenMRS system. I could not find person attribute which exist in a module. Person attributes are objects attached to a person object. By the way the patient and the user objects are derived classes of the person class. To make the tribe object a person attribute compatible object I have to implement the Attributable interface as the first step.
Tonight I went through the OpenMRS source and removed the tribe functionality. The useful parts were extracted to the new tribe module. The tribe module will host the tribe object and functionality to create, update and delete tribe modules. Tribe administration page will be hooked up to the OpenMRS from the OpenMRS administration page through an extension point. OpenMRS code is a pleasure to work with. In a couple of hours I was able to clean up the tribe code from the OpenMRS code.
Tribe project needs to create a OpenMRS module. There are lots of modules developed already which extend the core OpenMRS system with various enhancements. Some of them are listed in here. I started out with the basicmodule. Basic module provides the skeleton but a working module out of the box. I followed the instructions and created the module for the tribe feature.
Google Summer of Code 2008 work officially begins today. I am planning to finish up the Tribe module early as possible. In the OpenMRS domain model the patient object has an association to a tribe object, probably because OpenMRS implemenations started out mainly from African countries. But not all OpenMRS implemenations need to identify the tribe of a patient. So the objective is to remove the tribe object and the related functionalities out of the core OpenMRS system and make it into a pluggable module. Then the tribe module can be plugged into the core OpenMRS system where it is needed.
I got the book yesterday, Google is sending for all the Google Summer of Code students. The book, Beautiful Code, is a collection of articles by leading programmers and designers. They talk about their experiences architecting and designing good code. It is an nice gift, well thought out by Google.
Computer related books go out of date so quickly, sometimes in 2 – 3 months. But this book will last for a long time, I guess.
