One of the difficulties was with lookup values. An example was given of defining a new loan purpose to match a new loan purpose created in the PM system. This new loan purpose would be inserted directly into the database using SQL insert statements. Problems came when new lookup values were added in the next Mifos iteration. The new lookup values would have hard coded ids (rather than querying for the max id) and so the new ids introduced in a Mifos iteration would overwrite ids that had been created in the live Mifos instance. So there is an issue of how to handle onsite customizations such that they can integrate with evolution of the Mifos build in values.

Adding lookup IDs happens, for example, when an MFI adds a new ethnicity; see ConfigurationOptions#3_9_Look_up_options. We're not sure how MFI's have done this in 2006/2007, but as of July 2007 we have been working on a UI interface to add/edit/remove look-up options in Mifos.

Technical details

An upgrade script will need to not only assign an ID, but assign an ID and use that assigned ID in another row. For example, upgrade_to_101.sql used to contain:

INSERT INTO LOOKUP_VALUE VALUES(569,87,' ');
INSERT INTO LOOKUP_VALUE_LOCALE VALUES(914,1,569,'Can create multiple Loan accounts');

Here, 569 was fixed, but it should be assigned dynamically. More recent version of MIFOS handle the 101 upgrade via the class AddActivity, which assigns the number which is 569 in the above example.

For a more complete list of these upgrades, look at subclasses of the Upgrade class, and masterRegister in DatabaseVersionPersistence. The former are the upgrades which have been written so far. The latter is the equivalent to the upgrade_to_*.sql and downgrade_from_*.sql files.

See the test LatestTest#afterLookupValues - this test is now passing, indicating that this problem is solved (with respect to lookup values).

To do

*Any other numbers which need to be assigned dynamically other than lookup values?

*Take one or more real-life database dumps and try upgrading them. This should be a relatively effective way of figuring out what cases we haven't handled yet.

See Also