|
>>What could cause the primary key to be a problem in case someone builds an offline app?
The crux of this issue is related to syncing offline data
Assume that I am creating a client offline and would want to call MifosX API's when an internet connection is available to sync the data back to the system.
So, now after creating a client, say "Alex", assume (due to intermittent network, multiple sync attempts by user etc) that the MifosX API is accidentally called twice with the same data, The API should be smart enough to reject the second request as a duplicate (maybe a create client is not a good example, a better example would probably be loan and savings transactions)
So every time new data like a loan transaction is created offline, if it is associated with a UUID (which is then stored in the associated tables). The API would be able to identify and reject duplicate sync requests etc.
A simple approach for the same (without having to change Primary keys) would be adding a Unique Nullable UUID column to the table (MySQL supports multiple NULL values for Unique Constraint). So there would be no change to the existing API's other than adding an optional UUID. Existing online apps wouldn't need any change and new apps which need offline support would have to pass in the UUID along with the create requests.
That being said, I am not sure if other databases also allow Multiple Null values in Unique Columns (so this might make porting to a different database an issue)
|
MIFOSX-165
