Updated by Tommi on 2012-03-02 18:02:42 +00:00

• Category set to 24
• Status changed from New to Feedback
• Done % changed from 0 to 100

Its from dev git, right? Its not an error. You stepped into work in progress.
Here only the naming of the file is wrong, because it was intend for 1.7. Later we delayed V1.7. and ido2db is still operating (and askin for) dbversion=1.6.0. The update script includes only 2 new indexes up to now, which are requested from the web guys, but no real structural changes which requires a version update. If the new release is finished, also the update for the dbversion will be included. Maybe you will get an error message when running the final script, because the indexes are already in your system and cannot added twice. Than you should remember this.

Updated by mfriedrich on 2012-03-02 18:14:28 +00:00

• Target Version set to 1.7
• Done % changed from 100 to 0

well it is considered to be an "error" in regards of the update script - which will only touch the main sqls, but not the manual upgrade sqls.

i told him to create an issue and assign to you, because you created those (git log $file) and would know best how to proceed (fix now, fix on release, etc).

Updated by Tommi on 2012-03-02 20:08:18 +00:00

3 options

1. update ido2db and database version string to 1.7. But i understood this will be part of the release prozess
2. remove the patch from public access
3. rename the 1.7 files to somewhalt else

Updated by mfriedrich on 2012-03-02 22:29:50 +00:00

just look in the files... 1.6.0 is not correct and shoud not be forgotten. i don't care when this happens but it has to. keep cool ;-)

Updated by Tommi on 2012-03-03 10:02:11 +00:00

Its not forgotten. According to https://wiki.icinga.org/display/Dev/Releases this change is part of the release process.

./update-version-schema 1.5.0 2011-08-17

If its not true anymore, i can do this of course. But then you will need the updated ido2db binary as well after appliing the sql because of the version string check after connect. Otherwise ido2db will not write to the db.

Updated by Tommi on 2012-03-03 10:32:21 +00:00

• Done % changed from 0 to 100

applied in changeset 7de8a3e

Updated by mfriedrich on 2012-03-03 15:55:31 +00:00

Tommi wrote:

Its not forgotten. According to https://wiki.icinga.org/display/Dev/Releases this change is part of the release process.

no it is not. as said previously, the script only touches the mysql | pgsql | oracle.sql and not the -upgrade-$version.sql. that is developer responsibility and only for that reason i told our appreciated test padawan to create an issue for you.

the global schema update should be run during release preparations.

Updated by Tommi on 2012-03-03 16:23:52 +00:00

i cannot see the sense behind this seperation. the dbversion database field must match the entry in common.h, otherwise no data will be inserted. If i change only the value in upgrade.sql and leave common.h untouched ido2db will fail after running the upgrade script. If i change the common.h entry as well, ido2db will work after the update, but it will fail if the database has been build from scratch with mysql.sql.
Anyway, my last commit includes the dbversion update to 1.7.0 in all related files.

Updated by mfriedrich on 2012-03-03 18:17:05 +00:00

ok, booted the pc, cannot type on my mobile.

what are the steps when you change the db schema for a new version?

1. you change the main sql script (git diff mysql.sql e.g.)
   1a) you change to tests on a fresh import
   1b) you test the change with mysql, postgresql, oracle
2. you create the upgrade script. namely e.g. mysql-upgrade-$nextversion.sql
   2a) you add the change needed to update from previous version to the next, as the fresh import would diff to the previous one
   2b) you test that change on all rdbms
   2c) you add the dbversion update hardcoded by yourself
3. after having finished, and verified all changes ok, you commit those changes
4. when other devs and testers test the git commit in the dev branch ok, you upgrade the main version in git as well for the next release version. the upgrade will affect
   4a) common.h for the schema version
   4b) the main sqls for mysql/pgsql/oracle

you may now ask, why you need to manually set the version in the e.g. mysql-upgrade-$nextversion.sql
this happens for various reasons

1. the upgrade script does not automatically know that you have created the upgrade scripts (could be enhanced, but adds complexity which should not happen)
2. if you change your mind and remove the upgrade script, no need to run the schema update script while developing. sometimes changes during development are dropped or rescheduled. a simple "git revert " is easier than grepping around for version mismatches
3. and last but not least such diversity strengthens the "four eyes" principle to let people recheck everything before a release. you haven't seen the days where such things were not checked, and lead into funny release errors.

so i am pretty happy that frankstar did the test (wow someone that tests!!!) and reported is straight here.

hope that resolves the question marks at your stage - if he wouldn't have created the issue, i would have as soon as testing proposed changes.

Updated by Tommi on 2012-03-04 08:20:05 +00:00

there is no problem with me to get a ticket and do the fix.

but as i already mentioned i am feeling nessesary to stress the process point. i see a problem in the chain you described between step 3) and 4). The change i commited with the increased dbversion in update sql can only be tested in dev in terms of sql working, but with this patch applied ido2db is not working anymore, because the mandantory update in common.h is not there in this stage. Usually, i also change the main sql together with the update sql which i need to test in parallel and there i need the same results. If i should do this later it can really be forgotten. This because i would vote not to distribute the point to increase the dbversion string over the stages, but at all together either to time of the the first change or to the time of release. Maybe this explains my concerns better.

Updated by mfriedrich on 2012-03-04 12:12:51 +00:00

ok, finally understood. you mean the application itsself is indicating 1.6.0 while the db is already thinking 1.7.0 which will lead into syslog entries with version mismatches.

anyhow, then it remains necessary to do

• either run the update-schema-version when $dev adds the upgrade scripts
• or let the upgrade-schema-version check if such upgrade files exist (warn the $dev if not) and if, check if they provide the correct dbversion to be set (warn the 4dev and correct automatically)

i sort of like the second option more, but it still requires manual tests by those willing to do so (like frankstar).

Updated by Tommi on 2012-03-30 15:55:25 +00:00

• Status changed from Feedback to Resolved

no more feedback within the last 4 weeks for the actual issue, assume resolved

Updated by Frankstar on 2012-04-02 14:37:25 +00:00

Database changed
mysql> select * from icinga_dbversion;
+--------------+----------+---------+
| dbversion_id | name     | version |
+--------------+----------+---------+
|            1 | idoutils | 1.6.0   |
+--------------+----------+---------+
1 row in set (0.00 sec)

no update, still shows after upgrade 1.6.0
just to inform you

Updated by mfriedrich on 2012-04-02 14:41:06 +00:00

oracle works fine, using merged tree from mfriedrich/ido currently.

Updated by mfriedrich on 2012-04-02 14:44:18 +00:00

same goes for mysql.

i won't merge that tree though because of the recently introduced bug in #2342

check dev/ido for a current merge waiting for proper fix / revert.

Updated by Tommi on 2012-04-02 16:19:48 +00:00

is the the patch https://dev.icinga.org/projects/icinga-core/repository/revisions/7de8a3e7b9f96e77937ce4dd1a93f8eca1c150ce applied?

Updated by mfriedrich on 2012-04-02 16:21:47 +00:00

presumingly he does not use the correct git branch, as your commits did not hit master nor next currently.

this will help identify the cause

$ git log -1

Updated by mfriedrich on 2014-12-08 14:37:36 +00:00

• Project changed from 18 to Core, Classic UI, IDOUtils
• Category changed from 24 to IDOUtils
• Icinga Version set to 1
• OS Version set to any