MetaData handling for edits and updates

(cross-posted from JavaRosa developers forum)https://groups.google.com/forum/?fromgroups=#!topic/javarosa-developers/1JCOWALv3nI

Hi,

We are in the process of adding instance-edit functionality for already
submitted data to formhub/enketo and are looking into adding
instance-update functionality in the future. I'd like to ask for your
opinion on the proper way of using instanceID and deprecatedID meta data so
we can ensure this functionality is going to be compatible with other
OpenRosa servers and clients, as there are of course many ways of doing
this.

For clarity:

  • with 'edit' we mean removing errors and/or completing missing data (old
    instance can basically be discarded)
  • with 'update' we mean an entity such as a water well or child gets
    re-surveyed, e.g. every year (so the progress over time can be monitored)

Editing:
After reading the MetaData Schemehttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema, we
have the impression that deprecatedID is meant exactly for what we're
trying to do and would work like this: The original instanceID value is
copied to deprecatedID, the instanceID is emptied, and a new instanceID is
generated for the edited data.

  1. Is this understanding correct?

  2. If so, where, in your opinion, should the deprecatedID node be added
    (and be given the instanceID value):

    • at the server before serving the instance to the client for editing,
      or
    • at the client when receiving an instance for editing?

Updating:
In line what is mentioned under editing, we are wondering if a logical
standard approach to updating entities, would be to serve the old instance
but use a different meta data node, such as entityID, that perhaps contains
the first instanceID ever submitted to the server for that entity. A new
instanceID would be generated for the 'update'.

  1. Does this sound right, are there any plans to specify entity updates (or
    did we miss something) or do you have a different opinion?

Best regards,

Martijn van de Rijdt

The ODK team isn't planning any special functionality beyond whatever is in
javarosa.

Our 2.0 platform will support editing existing instances, but it will use
different technology under-the-covers.

Mitch

ยทยทยท On Thu, Oct 18, 2012 at 9:18 AM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:

(cross-posted from JavaRosa developers forum)https://groups.google.com/forum/?fromgroups=#!topic/javarosa-developers/1JCOWALv3nI

Hi,

We are in the process of adding instance-edit functionality for already
submitted data to formhub/enketo and are looking into adding
instance-update functionality in the future. I'd like to ask for your
opinion on the proper way of using instanceID and deprecatedID meta data so
we can ensure this functionality is going to be compatible with other
OpenRosa servers and clients, as there are of course many ways of doing
this.

For clarity:

  • with 'edit' we mean removing errors and/or completing missing data (old
    instance can basically be discarded)
  • with 'update' we mean an entity such as a water well or child gets
    re-surveyed, e.g. every year (so the progress over time can be monitored)

Editing:
After reading the MetaData Schemehttps://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema, we
have the impression that deprecatedID is meant exactly for what we're
trying to do and would work like this: The original instanceID value is
copied to deprecatedID, the instanceID is emptied, and a new instanceID is
generated for the edited data.

  1. Is this understanding correct?

  2. If so, where, in your opinion, should the deprecatedID node be added
    (and be given the instanceID value):

    • at the server before serving the instance to the client for editing,
      or
    • at the client when receiving an instance for editing?

Updating:
In line what is mentioned under editing, we are wondering if a logical
standard approach to updating entities, would be to serve the old instance
but use a different meta data node, such as entityID, that perhaps contains
the first instanceID ever submitted to the server for that entity. A new
instanceID would be generated for the 'update'.

  1. Does this sound right, are there any plans to specify entity updates
    (or did we miss something) or do you have a different opinion?

Best regards,

Martijn van de Rijdt

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com