db-schema

Commit Graph

Author	SHA1	Message	Date
Jon Bonilla	20816f3305	Try to fix kamailio.lcr_gw.group_id 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.	14 years ago
Jon Bonilla	cd76e18027	Try to fix the lcr_rule key issue #1967 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.	14 years ago
Andrew Pogrebennyk	1c5dc3596c	return column lcr_gw.group_id, update key on lcr_rule to include request_uri	14 years ago

Author

SHA1

Message

Date

Jon Bonilla

20816f3305

Try to fix kamailio.lcr_gw.group_id

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.

Jon Bonilla

cd76e18027

Try to fix the lcr_rule key issue #1967

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.

Andrew Pogrebennyk

1c5dc3596c

return column lcr_gw.group_id, update key on lcr_rule to include request_uri

3 Commits (mr3.8.9)