POST 'created', 'lastUpdated' in /api/metadata

Hi Mahendra

One issue we are seeing quite often is that people don’t update the lastUpdated field, they simply get the payload, do their updates, and send it back (without updateing lastUpdated)

Would it be ok to check for both null AND to see if the new lastUpdated is > old lastUpdated, we do want the field to be updated, to reflect updates… since it is in use for filtering etc

Are you OK with that?

···

On Mon, Dec 22, 2014 at 11:41 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi Lars/Morten,

Please find attached the patch.

It has two changes.

  1. In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
  2. In AttributeValue, we have added two more columns viz. “created” and “lastupdated”. In DefaultIdentifiableObjectImporter, we are setting the values of both fields to current date, if their values in the payload is null.
    Please review and try to merge to trunk ASAP.

Thanks.


Morten

On Mon, Dec 22, 2014 at 10:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi,

We are developing an offline client for DHIS which syncs to the server whenever the internet connection is available. To sync the metadata (like org units, etc) created or updated on the offline client, we want DHIS to save the “lastUpdated” and “created” fields from the payload of POST request to /api/metadata. This will help us resolve merge conflicts during sync.

Currently, this is not supported. Irrespective of the value of “lastUpdated” and “created” fields in the payload, DHIS is always taking server time.

We are planning to implement this in DHIS and send a patch. Let us know your thoughts.

For a bundle of reasons it would be much better for the lastUpdated field to be updated as a default value on the database rather than explicitly through the api. I would rather discourage its use through the api rather than enforce it.

···

On 22 December 2014 at 11:16, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Mahendra

One issue we are seeing quite often is that people don’t update the lastUpdated field, they simply get the payload, do their updates, and send it back (without updateing lastUpdated)

Would it be ok to check for both null AND to see if the new lastUpdated is > old lastUpdated, we do want the field to be updated, to reflect updates… since it is in use for filtering etc

Are you OK with that?


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Morten

On Mon, Dec 22, 2014 at 11:41 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi Lars/Morten,

Please find attached the patch.

It has two changes.

  1. In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
  2. In AttributeValue, we have added two more columns viz. “created” and “lastupdated”. In DefaultIdentifiableObjectImporter, we are setting the values of both fields to current date, if their values in the payload is null.
    Please review and try to merge to trunk ASAP.

Thanks.

On Mon, Dec 22, 2014 at 10:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi,

We are developing an offline client for DHIS which syncs to the server whenever the internet connection is available. To sync the metadata (like org units, etc) created or updated on the offline client, we want DHIS to save the “lastUpdated” and “created” fields from the payload of POST request to /api/metadata. This will help us resolve merge conflicts during sync.

Currently, this is not supported. Irrespective of the value of “lastUpdated” and “created” fields in the payload, DHIS is always taking server time.

We are planning to implement this in DHIS and send a patch. Let us know your thoughts.

+1 for no updates to this through the WebAPI.

With globally distributed systems, it makes little sense to update these fields with stuff from clients who are on different time zones, and who have unsynchronized clocks, much less to say if they just send bogus information.

Same should go for lastUpdated in the data value table I think. Data imports should never be able to import either lastUpdated , as this is really something specific to a particular instance.

Regards,

Jason

···

On Mon, Dec 22, 2014 at 12:41 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

For a bundle of reasons it would be much better for the lastUpdated field to be updated as a default value on the database rather than explicitly through the api. I would rather discourage its use through the api rather than enforce it.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

On 22 December 2014 at 11:16, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Mahendra

One issue we are seeing quite often is that people don’t update the lastUpdated field, they simply get the payload, do their updates, and send it back (without updateing lastUpdated)

Would it be ok to check for both null AND to see if the new lastUpdated is > old lastUpdated, we do want the field to be updated, to reflect updates… since it is in use for filtering etc

Are you OK with that?


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Morten

On Mon, Dec 22, 2014 at 11:41 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi Lars/Morten,

Please find attached the patch.

It has two changes.

  1. In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
  2. In AttributeValue, we have added two more columns viz. “created” and “lastupdated”. In DefaultIdentifiableObjectImporter, we are setting the values of both fields to current date, if their values in the payload is null.
    Please review and try to merge to trunk ASAP.

Thanks.

On Mon, Dec 22, 2014 at 10:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi,

We are developing an offline client for DHIS which syncs to the server whenever the internet connection is available. To sync the metadata (like org units, etc) created or updated on the offline client, we want DHIS to save the “lastUpdated” and “created” fields from the payload of POST request to /api/metadata. This will help us resolve merge conflicts during sync.

Currently, this is not supported. Irrespective of the value of “lastUpdated” and “created” fields in the payload, DHIS is always taking server time.

We are planning to implement this in DHIS and send a patch. Let us know your thoughts.

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Hi

I have now applied this functionality in rev 17861 (some minor differences, so I didn’t use the patch).

Please be aware that the default strategy for our objects that are not idObject is to delete, and re-add, the effect of this is that created = lastUpdated for every attribute-value. I’m hoping to fix this in the next version of the importer, but for your use-case I think having the lastUpdated field is good enough.

···

On Mon, Dec 22, 2014 at 5:40 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

+1 for no updates to this through the WebAPI.

With globally distributed systems, it makes little sense to update these fields with stuff from clients who are on different time zones, and who have unsynchronized clocks, much less to say if they just send bogus information.

Same should go for lastUpdated in the data value table I think. Data imports should never be able to import either lastUpdated , as this is really something specific to a particular instance.

Regards,

Jason

On Mon, Dec 22, 2014 at 12:41 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:

For a bundle of reasons it would be much better for the lastUpdated field to be updated as a default value on the database rather than explicitly through the api. I would rather discourage its use through the api rather than enforce it.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

On 22 December 2014 at 11:16, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Mahendra

One issue we are seeing quite often is that people don’t update the lastUpdated field, they simply get the payload, do their updates, and send it back (without updateing lastUpdated)

Would it be ok to check for both null AND to see if the new lastUpdated is > old lastUpdated, we do want the field to be updated, to reflect updates… since it is in use for filtering etc

Are you OK with that?


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp


Morten

On Mon, Dec 22, 2014 at 11:41 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi Lars/Morten,

Please find attached the patch.

It has two changes.

  1. In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
  2. In AttributeValue, we have added two more columns viz. “created” and “lastupdated”. In DefaultIdentifiableObjectImporter, we are setting the values of both fields to current date, if their values in the payload is null.
    Please review and try to merge to trunk ASAP.

Thanks.

On Mon, Dec 22, 2014 at 10:55 AM, Mahendra Kariya mahendra.kariya@thoughtworks.com wrote:

Hi,

We are developing an offline client for DHIS which syncs to the server whenever the internet connection is available. To sync the metadata (like org units, etc) created or updated on the offline client, we want DHIS to save the “lastUpdated” and “created” fields from the payload of POST request to /api/metadata. This will help us resolve merge conflicts during sync.

Currently, this is not supported. Irrespective of the value of “lastUpdated” and “created” fields in the payload, DHIS is always taking server time.

We are planning to implement this in DHIS and send a patch. Let us know your thoughts.