Koozali.org: home of the SME Server

SME8FA18V311-16 DAHDI Fix

Offline apmuthu

  • *
  • 244
  • +0/-0
Re: SME8FA18V311-16 DAHDI Fix
« Reply #15 on: January 19, 2013, 10:03:02 PM »
I am working on the upgrade issue for customers.

New installs must however be from the latest standpoint even if an always updated sarknew.db needs to be put in.

Take a decision about the earliest sail db you wish to support. Then make one consolidated update to bridge each major version - say 2.2 -> 2.3 -> 2.4 -> 2.6 -> 3 -> 3.1 -> 3.1.1 -> 4 (and 3.2 -> 4). Take the first known schema for each version and provide upgrades only to the latest version. Since there are only a few tables, a proper ERD can be published with notes on usage and way forward in development.

The following issues have been found so far.

The sarkstart.db Device table has entries for snom820.htm and snom870.htm - both have xml provisioning. Similarly named ones with htm provisioning is in r1673. Similarly Snom VXT with xml provisioning is present in the sarkstart.db and the same Device name with htm provisioning is in r1751.

Further duplication is observed in r1751 in the case of the Device Aastra VXT, besides the sarkstart.db itself has duplicates named differently - AastraVXT and Aastra VXT.

Many of the files in the amacs folder have dates that do not correspond with their revision numbers sequence. I take the date first and then use the revision numbers within them in ascending order.

I have prepared a consolidated sql file with comments prefixed with double dashes and removed double quotes where possible. I have retained the case sensitivity as per the table names (Carrier for carrier, Cluster for cluster, etc) if only for the sake of uniformity.

If we drop the undolog table it should not affect the SAIL install - am I correct?

Other than for the two big inserts in r1673 and r1751, I have managed to make all INSERTs into INSERT OR IGNORE followed by UPDATE statements. Quite a few ALTER TABLE ADD COLUMN statements are redundant and some being already done in the sarkstart.db itself!

When one SQL statement in a file fails, all others in the file fail to get executed. Hence the ALTER TABLE ADD COLUMN will cause gaps in such execution if and when they fail. I am going thru the sequence of checking for such breaks - 28th time now....

Why were the SPA-3000FXS and SPA-3102FXS deleted from the Device table in r1577 ?

I have retained them pending clarification.

The sarknew.db and the consolidated sql upgrade script for SAIL v3.1.1-20 are available here.
« Last Edit: January 19, 2013, 10:36:18 PM by apmuthu »