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.orgStefan Sperling has posted comments on this change. ( https://gerrit.osmocom.org/11898 ) Change subject: add database schema versioning to the HLR database ...................................................................... Patch Set 1: (1 comment) https://gerrit.osmocom.org/#/c/11898/1/sql/hlr.sql File sql/hlr.sql: https://gerrit.osmocom.org/#/c/11898/1/sql/hlr.sql@48 PS1, Line 48: -- last_lu_seen TIMESTAMP default NULL > I'm fine with possibility to update on the fly, but why requiring everybody who uses this . […] I understand where you are coming from. Having spent some time on this already, and having already tried both approaches, my current response to this request is: Yes it would be nice, but it's not trivial to do. One advantage of the proposed method is that schema upgrades will be extensively tested. Another is that we have a single code path which covers all of these cases: - A new DB is created from scratch. - An existing DB which confirms to the current schema is opened. - An existing DB which needs to be upgraded is opened. And schema upgrades are a very cheap one-time operations, so the cost at run-time is minimal. The main downside is of course that the complete schema can only be obtained by running '.fullschema' on an hlr.db. I couldn't yet find a working solution when the schema is created with the current format to begin with and works for all 3 cases outlined above. There are several error conditions which show up in various approaches I have tried, and they are all somehow linked to sqlite's limited support for ALTER TABLE. The ALTER TABLE statement cannot be prepared if the last_lu_seen column already exists: DDB ERROR (1) duplicate column name: last_lu_seen (db.c:88) DDB ERROR Unable to prepare SQL statement 'ALTER TABLE subscriber ADD COLUMN last_lu_seen TIMESTAMP default NULL If the meta data version is inserted by hlr.sql, then upgrades don't work because an existing subscriber table can't be modified by hlr.sql. But the upgrade code sees version number 1 and won't alter the table, so preparing our statements now fails with: DDB ERROR (1) no such column: last_lu_seen (db.c:88) DDB ERROR Unable to prepare SQL statement 'SELECT id,imsi,msisdn,vlr_number,sgsn_number,sgsn_address,periodic_lu_tmr,periodic_rau_tau_tmr,nam_cs,nam_ps,lmsi,ms_purged_cs,ms_purged_ps,last_lu_seen FROM subscriber WHERE imsi = ?' (db.c:424) Also note that the sqlite API does not provide distinct error codes that tell us why a statement failed, which makes it difficult to handle such specific error cases in C code. It can likely be done somehow, but as far as I can tell it will require more code, not less. Do you have a working suggestion? This would all be much easier if a version number had been included in the DB schema the first place. -- 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: 1 Gerrit-Owner: Stefan Sperling <ssperling at sysmocom.de> Gerrit-Reviewer: Jenkins Builder (1000002) Gerrit-Reviewer: Stefan Sperling <ssperling at sysmocom.de> Gerrit-CC: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Comment-Date: Fri, 23 Nov 2018 10:31:32 +0000 Gerrit-HasComments: Yes Gerrit-HasLabels: No -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181123/9e502e05/attachment.htm>