Change in osmo-hlr[master]: add database schema versioning to the HLR database

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 Nov 30 11:40:53 UTC 2018


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

Change subject: add database schema versioning to the HLR database
......................................................................


Patch Set 5:

(4 comments)

https://gerrit.osmocom.org/#/c/11898/5/src/Makefile.am
File src/Makefile.am:

https://gerrit.osmocom.org/#/c/11898/5/src/Makefile.am@119
PS5, Line 119: 	echo "/* DO NOT EDIT THIS FILE. It is generated from files in osmo-hlr.git/sql/ */" > "$@"
> (wow, I really cooked up some voodoo here didn't I ... now wondering whether a python script "sql2c. […]
Yes, later putayta.


https://gerrit.osmocom.org/#/c/11898/5/src/db.c
File src/db.c:

https://gerrit.osmocom.org/#/c/11898/5/src/db.c@378
PS5, Line 378: 	rc = sqlite3_exec(dbc->db, "PRAGMA journal_mode=WAL; PRAGMA synchonous = NORMAL;", 0, 0, &err_msg);
> (interesting typo in old code: "synchronous" […]
This should not break anything.
It seems this statement is trying to switch the synchronous pragma from 'FULL' to 'NORMAL'.
In a hlr.db freshly created by running osmo-hlr, the pragma is set to 'FULL' by default.
Because 'FULL' is more paranoid than 'NORMAL', we didn't lose anything here except for negligible performance differences.
See https://sqlite.org/pragma.html#pragma_synchronous


https://gerrit.osmocom.org/#/c/11898/5/src/db.c@383
PS5, Line 383: 	if (!db_is_bootstrapped(dbc)) {
> imagine some future scheme adds a new table. […]
The idea is that this function will only ever check for tables which were already known in schema version 0.
In which case the problems you point out won't occur.
Maybe I should add a comment about that.

Checking for tables which are added in later schema versions should be done as an additional later step.
There's a bit of a blurry line between checking for being bootstrapped and full-on schema verification; so we'll have to find some acceptable trade-off.


https://gerrit.osmocom.org/#/c/11898/5/src/db.c@403
PS5, Line 403: 		LOGP(DDB, LOGL_ERROR, "Unable to read user version number from database '%s'\n", dbc->fname);
> Is the user_version always present in an sqlite db? otherwise, if I read this right, when osmo-hlr n […]
No, it will only return -1 if queries return errors.

It seems to me like user_version will always be zero unless we explicitly set it.
On an empty sqlite DB, pragma user_version returns zero.



-- 
To view, visit https://gerrit.osmocom.org/11898
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: I8aeaa9a404b622657cbc7138106f38aa6ad8d01b
Gerrit-Change-Number: 11898
Gerrit-PatchSet: 5
Gerrit-Owner: Stefan Sperling <ssperling at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Stefan Sperling <ssperling at sysmocom.de>
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Comment-Date: Fri, 30 Nov 2018 11:40:53 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181130/ca3cf4c1/attachment.htm>


More information about the gerrit-log mailing list