What is the general goal of the feature?
Possibility to preload data on tablet from a dynamicly modified CSV file.
What are some example use cases for this feature?
As soon as a respondents name is registered (or an ID) with ODK and uploaded to aggregate, that CSV form should be dynamically be upgraded/modified. As soon as you pull that ID data from Aggregate to your tablet the CSV list with ID's must always be modified with the latest ID's
What can you contribute to making this feature a reality?
Yes, financially. I am trying to arrange funding for development. I see two options: Build on ODK or plug into an existing open source software package. Would be great if the ODK community could advise me on this what is best. It should preferably opensource or a not-for-profit software because we don't want a locked-in situation in the future (e.g. high pricing, or lacking features)
Hi Yanokwa, I read these topics but my question is a bit different in a sense that I just want to have our CSV file (with lookup values) to be automatically updated when data (with new lookup values) is send to our aggregate server. When another person pulls the field form, he/she should be able to use the new lookup values. I would like to work with ID's, so such a feature would be very useful.
Do you ever have duplicate IDs when you do this now with manual preloads? If so, how do you resolve those duplicates? And how would you expect the server to resolve them (take the first entry, take the last entry, ignore all dupes)?
Not sure how Eddy does this however Smap implements it with a key policy. You can specify a "key" for a survey along with a policy of "add", "merge" or "discard". So if you get a new submission added with the same key that submission is processed according to the key policy. The default is obviously "add". "Discard" is the traditional policy for unique keys in databases but probably not so useful in odk based systems. Merge is the policy you want to incorporate new values into an existing submission while retaining a unique key. I guess I could also add a policy of replace.