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
In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
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.
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
In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
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.
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.
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.
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
In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
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.
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.
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.
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.
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
In BaseIdentifiableObject.setAutoFields(), it sets the last updated time to current time only if the value from payload is null.
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.
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.