fix trigger enum_set_default introduced with r9086
to correctly update voip_*_preferences with default values
for preferences that cover more than one in (usr|dom|peer)_preferences.
fix trigger enum_update introduced with r9149 to only update values of
enum preferences in voip_(usr|dom|peer)_preferences that where actually
set to that value (previously all preferences were updated).
If --no-data is *not* used in the mysqldump command line of
trunk deployments then we get stuff like that into our svn
repository committed:
| > -INSERT INTO `subscriber` VALUES
| (1,'no_such_number','voip.sipwise.local','499187eef57cdee845f8e98bf81c04b4','','1cece14d3af643f05273228e790ce1b7','90d1398
| 204f968fc9bca32689d933b90',NULL,'9bcb88b6-541a-43da-8fdc-816f5557ff93','','2012-09-03
| 16:02:41'),(2,'nagios','voip.sipwise.local','nagios4Sipwise!','','e5290263a1b27f90c5630eecc7319715','aba8e5f08f6fc0dd1e18e
| 9e27550b8f0',NULL,'ac1697cf-6933-45ef-9abf-b1278054ded0','','2012-09-03 16:02:41');
| > +INSERT INTO `subscriber` VALUES
| (1,'no_such_number','voip.sipwise.local','3ce39530696080435b2625be8de48786','','d2635d573e32f8e49bea5b8244d6f54f','457794a
| 1beffd43c1cbe04e3cb5c0229',NULL,'9bcb88b6-541a-43da-8fdc-816f5557ff93','','2012-09-03
| 16:24:36'),(2,'nagios','voip.sipwise.local','nagios4Sipwise!','','e5290263a1b27f90c5630eecc7319715','aba8e5f08f6fc0dd1e18e
| 9e27550b8f0',NULL,'ac1697cf-6933-45ef-9abf-b1278054ded0','','2012-09-03 16:24:36');
| [...]
To avoid those moving timestamp changes hit our svn repos
we replace all function calls to "now()" with just '0'.
Also see discussion on development@sipwise.com with thread
subject "[VCS/DEV] r10942 - ngcp/db-schema/trunk/schema"
Acked-by: Daniel Tiefnig
Acked-by: Jon Bonilla
From: Michael Prokop <mprokop@sipwise.com>
If there are unsynced gws in kamailio database
because the db schema was corrupt this rev
should align the existing group_id fields and
remove the orphaned ones.
Thx agranig
It will be executed with no changes on new
deploys and new upgrades since the changes are
already edited in previous revs.
For those ones which already applied the original
revs this one will fix the asyncs but still won't
delete the inconsistent entries delted in
provisioning and still present in kamailio.
That's for another rev.
It's dropped an recreated. That makes the
group_id values are generated with the
default ones and that's not what we have in
provisioning database. The triggers fail as those
fields don't match.
The ley that is tried to be created in 9868.up
has no group_id field so it won't be applied in
case you already have two peering groups with
same peering rules. In case you don't it will
apply but the resulting 2.6 version won't allow
you to have different peering groups with same
peering rules.
The solution is what follows: We edit the
existing db scripts to allow upgrades to work
well. This will make existing 2.6 systems and
new 2.6 systems to have different db scehmas.
And the existing ones will be still broken. A new
db rev 10860.up has been created to unify both
kind of systems (the ones which executed the
original revs and the ones which excuted the
edited ones) and it will also fix the existing
versions as it will be executed in existing 2.6
systems via postinst script.
Why postinst script? We can't trust users to
execute update-db-schema as we don't know all
of them. It's better to handle this automatically.
This postinst addition is being handled by Mika
in another commit.
* backward-compatible defaults: NPN is default for outbound_pai, UPN for
outbound_from_user.
* update cli & user_cli preferences description.
* drop omit_outbound_displayname preference (obsolete since r9312).
- now it is also possible to select value "none" for outbound headers on
subscriber level to override the domain settings;
- update description for outbound header settings to explicitly state that
this has effect on calls from platform when the user is a _callee_.
- remove explicit MyISAM specification, let's stick to default InnoDB;
- as workaround for now use latin1 for tables which have large indexes to avoid
ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes.
now it should be up to date
TODO: add note to documentation on upgrade that says to go to peer/dom and
enable session timers if they have been used in previous version.