Identifier handling - StraboSpot/strabo-mobile GitHub Wiki

Currently (2015-05-01), when a spot is created in mobile, it gets a temporary ID on the device. When the data are uploaded to the server, all data existing for the project to which the data are assigned are deleted on the server. All IDs in the uploaded data are reassigned by the server, updating any foreign keys as well to maintain links. NOTE_-- if the data were downloaded from the server, the IDs that the server had are replaced when the data are uploaded again. Thus if there are links between data in different projects they will be broken.

Need to think through the assignment and maintenance of identifiers.

The intension of the system is to enable disconnected data entry instance to be creating data and then pushing to a central master (neo4j-- I'll call it StraboMaster). I don't think that we need to be locked into a design where all identifiers originate with the StraboMaster. A namespace approach to identifiers allowing local/off line identifier assignmet would make the sync process much easier and lighter weight on the mobile client. Here's one possible design:

StraboMaster assigns a 3 character (alphanumeric, start with alpha) stub to each user and each project. Null project is 'aaa', Null user is 'aaa'. When a user installs app they are asked to connect straboMAster and either create a user account or log in to their existing account. this gets their user prefix, and the prefixes for the projects they have access to edit. Assume for now that the 'project' construct is specific to a user, for their use to group spots. Grouping of data into larger projects (like a funded research project in a specific study area) will have to be done at a higher level. I suggest renaming this current 'project' construct to 'group' or 'dataset', and leave 'project' to better correspond to a research project that may have multiple users. The client app then generates id's by using a prefix that concatenates user and project stub strings, and a suffix that is unique and generated by the client. Data that are not bound to a project have the user stub and the null project stub. If the user declines connecting to StraboMaster to get stubs, the prefix defaults to 'aaaaaa'. A simple way is to use incrementing 10 digit integer (puts a limit on number of spots in a 'project'). In order for this to work, when the install gets the initial stub prefixes, or does a sync, the current max ID value is also obtained from the server and the client increments from there. On sync, uploaded IDs should be compared with existing IDs, and if a duplicate is found default behavior is to assume an update and replace the existing record. (Neo4j should keep an edit history allowing roll back if necessary). Could have switch to default to putting records with dup ID into some kind of holding tank, or to having server assign new ID that gets pushed back to client, which then has to update the ID and all places it is used as a referece/link between spots.