You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of "recvTimeTs": "1402409899391", use a Date object.
Nevertheless, an interesting behaviour to take into account: Date objects store miliseconds-based timestamps, but the Mongo console shows things like ISODate("2012-12-19T06:01:17.171Z"). This human-redable version of the timestamp may make unnecessary our "recvTime" field within the Json documents.
We should check if MySQL and CKAN have objects working in the same direction; if they have such objects, their usage should be study in order to probably remove the "recvTime" field in those backends. The problem here is HDFS, which does not have such a functionality and will be the unique backend keeping the "recvTime" field. This would break the homegeneity regarding the information all the backends are storing.
Effort: 1 man day
The text was updated successfully, but these errors were encountered:
Depending on "implementation timing" migration scripts may be required. For example, if Cygnus 0.8.0 is released before implementing this (either in FIWARE or IoP) and people starts using the Mongo sink, a migration script would be needed to transform from string-based recvTimeTs to Date() based recvTimeTs.
Similar situation with MySQL (in this case, Cygnus with the support to MySQL has been already released, so the need for the migration script/procedure is confirmed in this case).
At first stage, OrionMongoSink will add this ISODate objects for the recvTime field. In addition, recvTimeTs will be discarded. The same way current STH implementation works.
Instead of
"recvTimeTs": "1402409899391"
, use a Date object.Nevertheless, an interesting behaviour to take into account: Date objects store miliseconds-based timestamps, but the Mongo console shows things like
ISODate("2012-12-19T06:01:17.171Z")
. This human-redable version of the timestamp may make unnecessary our "recvTime" field within the Json documents.We should check if MySQL and CKAN have objects working in the same direction; if they have such objects, their usage should be study in order to probably remove the "recvTime" field in those backends. The problem here is HDFS, which does not have such a functionality and will be the unique backend keeping the "recvTime" field. This would break the homegeneity regarding the information all the backends are storing.
Effort: 1 man day
The text was updated successfully, but these errors were encountered: