Change in osmo-hlr[master]: store timestamp of last location update seen from subscriber

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Stefan Sperling gerrit-no-reply at lists.osmocom.org
Fri Dec 7 11:04:36 UTC 2018


Stefan Sperling has posted comments on this change. ( https://gerrit.osmocom.org/12121 )

Change subject: store timestamp of last location update seen from subscriber
......................................................................


Patch Set 5:

(4 comments)

https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG
Commit Message:

https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG@11
PS5, Line 11: in the 'subscriber' table, in granularity of seconds.
> (imho what the value means should be in a code comment and not so much in a commit log)
The value is indeed UTC.

The conversion from local time to UTC is done by SQlite.
I wrote a patch to convert to UTC in our C code, but with that patch the conversion happens twice, so I had to discard this patch.
Instead I have added a comment which documents what SQlite will do with the timestamp.


https://gerrit.osmocom.org/#/c/12121/5//COMMIT_MSG@19
PS5, Line 19:   901990000000001|2018-12-04 14:17:12
> I wonder why we don't store it as num of seconds since 1970. […]
Our code only deals with seconds since epoch.

SQlite is transforming from seconds since epoch to a string.
The reverse transformation can probably be done by SQlite as well; if not, we could easily do it in C.

I think storing the time as a string is great for users because an epoch timestamp is meaningless to humans.
It also makes future VTY timestamp display trivial (just print a string).


https://gerrit.osmocom.org/#/c/12121/5/sql/hlr.sql
File sql/hlr.sql:

https://gerrit.osmocom.org/#/c/12121/5/sql/hlr.sql@42
PS5, Line 42: 	last_lu_seen TIMESTAMP default NULL
> found https://www.sqlite.org/lang_datefunc. […]
I also noticed that documentation seems to be lacking here.
My tests are producing good results though.


https://gerrit.osmocom.org/#/c/12121/5/src/db_hlr.c
File src/db_hlr.c:

https://gerrit.osmocom.org/#/c/12121/5/src/db_hlr.c@637
PS5, Line 637: 		       "Cannot update LU timestamp for subscriber ID=%"PRId64": SQL error: (%d) %s\n",
> Be careful in general with interleavin strings and PRId64 type of strings, I recall seeing compilers […]
This problem also affects many other existing strings in this file.
So I would defer this to a separate patch.



-- 
To view, visit https://gerrit.osmocom.org/12121
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-hlr
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ibeb49d45aec18451a260a6654b8c51b8fc3bec50
Gerrit-Change-Number: 12121
Gerrit-PatchSet: 5
Gerrit-Owner: Stefan Sperling <stsp at stsp.name>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Stefan Sperling <stsp at stsp.name>
Gerrit-CC: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Comment-Date: Fri, 07 Dec 2018 11:04:36 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181207/d1f9ea20/attachment.htm>


More information about the gerrit-log mailing list