[dev.icinga.com #2394] After DB Upgrade (1.6.0 to 1.7.0) icinga_dbversion shows 1.6.0 #899
Comments
Updated by Tommi on 2012-03-02 18:02:42 +00:00
Its from dev git, right? Its not an error. You stepped into work in progress. |
Updated by mfriedrich on 2012-03-02 18:14:28 +00:00
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
|
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.
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
applied in changeset 7de8a3e |
Updated by mfriedrich on 2012-03-03 15:55:31 +00:00 Tommi wrote:
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. |
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?
you may now ask, why you need to manually set the version in the e.g. mysql-upgrade-$nextversion.sql
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
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
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
|
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
|
Updated by mfriedrich on 2014-12-08 14:37:36 +00:00
|
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2394
Created by Frankstar on 2012-03-02 16:10:48 +00:00
Assignee: Tommi
Status: Resolved (closed on 2012-03-30 15:55:25 +00:00)
Target Version: 1.7
Last Update: 2014-12-08 14:37:35 +00:00 (in Redmine)
Command:
upgrades DB succesfully but
shows
Changesets
2012-03-03 10:30:00 +00:00 by Tommi 7de8a3e
2012-04-22 10:13:55 +00:00 by mfriedrich 59645a8
2012-04-27 16:20:54 +00:00 by mfriedrich c149a8e
The text was updated successfully, but these errors were encountered: