Unique ID field


#1

I register people in the field. I want to have unique IDs with each record. Because I want to use that ID to specify participants to activities. so our personnel will look at registration form, copy ID and paste it to acitivty participation form

I have seen that _uuid and _id fields had been already filled when form was submitted.

uuid seemed a bit ugly and difficult to work for humans
can I use _id field to uniquely identify a record for this purpose?

thanks.


#2

mskaraca, you can use the “instance_name”, to generate unique ID.


#3

Thanks for quick response.

AFAIU, instance_name in the settings tab can be used to generate composite text

I prefer a number here.
_id seems to be number…


#4

Please note that the value of instance_name is entirely calculated by the specific form, so to the extend the value is ‘unique’ depends entirely on how dilligent the original form-writer was in constructing it (and in most cases its based off a UUID in any case…)

In order to ‘uniquely’ identify submissions, you first need to decide whether the id needs to be unique within a form (all versions thereof), a specific form version, all submissions from a specific device, or all submissions across all devices. Typically, if you really want to uniquely identify a specific submission (irrespective of who submitted it on what device) then you’ll have to use a UUID. UUIDs are long and ‘ugly’, but that is simply because they have to be long enough (ie enough bits) that their randomly-generated value is - statistically speaking - pretty much guaranteed never to be reproduced in your lifetime.


#5

Thanks for insights
I really want to stay away from uuid…SO I am really interested with _id field :slight_smile:

I want to use an ID for each registration form submission.

Later, this ID will be primary key for this record in our DB. Can I use _id field? only requirements are it must be unique for each submission and after editing of the submitted form, it must not change.

how _id field is generated? is it unique to all for submissions?

thanks again…


#6

As indicated in my above link - http://xlsform.org/en/#specify-form-submission-name - the uniqueness of id/instance_name is entirely dependent on how the form writer/designer chooses to define it. If they use a calculation incorporating uuid() then it’ll be unique across all forms and devices; if they use deviceid then it’ll be unique across devices but all the submissions from a particular device with have the same id/instance_name obviously, etc.

If you require a universally unique id - ie one that is pretty much guaranteed to be unique across all devices and submissions - then you’ll have a hard time getting away from uuid() [sic]. If you want a simpler id like 12345, this requires some sort of centralized id (ie ‘ticket’) generator that issues a new numeric (eg counter) id upon request. The problem is this model doesn’t work if you are collecting data offline - you fundamentally cant have a centralized ticket generator and offline data capture.

If you want to entirely avoid uuid(), you could construct a id using either deviceid, subscriberid or simserial (see ODK metadata for details), which should uniquely identify the device from which the submission originated. And then add to this (unique) string the form id (which should be unique wrt your organization), and then exploit ODKs so-called ExIntegerWidget to retreive a monotonically increasing counter from the ODK Counter app; as described here. That should give you a unique id string.

Which is all to say, generating truly unique ids offline, that is without some sort of centralized ticket generator, is fundamentally a tricky problem. This is why in many cases primary keys are generated by the database itself (eg using AUTO_INCREMENT), and not obtained from the client; the DB is basically acting as the ‘ticket’ issuer. And if you want to avoid client-generated uuids then you’ll probably have to perform some fairly involved technical acrobatics to accomplish it.


#7

Hi Xiphware

Thanks for explanations. I have some misunderstandings, let me clarfiy them.

1- I don’t want a universillay unique ID. I only need uniqe ID for each submission only for this form.

2- _id field is automatically added by kobo in my form submission data. I did not add an instance_name entry in my form. this is the case for uuid too. SO I wondered how kobo calculated this field in my submission. moreover if I use briefcase to pull this submission, delete submission (through kobo GUI, push submission (through briefcase) this _id field is regerenrated differently from the original one. But interestingly uuid remains the same…

If I make this _id field remains the same through briefcase pull/push movements then I want to use it.

For now, I have added a field to calculate time information upto milliseconds.this should be enough to prevent conflicts.

As you have already said, we need definetly a counter like DB auto_increment feature. We should subscribe for it and use it in our form. But kobo lacks this feature.

3- Lastly, we want to use kobo mostly in our offices throug PCs… from time to time, we will use it in the field. so we are mostly unable to use kobo collect and other android metadata.

I have seen that kobo is efficient in the field. But for offices we need more than passive data collecting. we need to query and relate data. SO kobo should not be a final environment for us in the long future…