I am committing this if we don't get a reasonable explanation why we should keep checking more then DatabaseUpgradeChecker itself.
rgards, On Tue, Sep 24, 2013 at 6:26 PM, daan Hoogland <daan.hoogl...@gmail.com>wrote: > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14231/ > > engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java<https://reviews.apache.org/r/14231/diff/1/?file=353986#file353986line387> > (Diff > revision 1) > > public void check() { > > 387 > > currentVersion = > this.getClass().getSuperclass().getPackage().getImplementationVersion(); > > Could we check for an interface, allowing an ancestor between this and > Object to supply the version? your argument makes sense, your solution seems > drastic given that womeone took the trouble to write this code. > > > - daan Hoogland > > On September 19th, 2013, 5:03 p.m. UTC, Darren Shepherd wrote: > Review request for cloudstack, Alex Huang and daan Hoogland. > By Darren Shepherd. > > *Updated Sept. 19, 2013, 5:03 p.m.* > *Repository: * cloudstack-git > Description > > Currently DatabaseUpgradeChecker determines the code version by doing > this.getClass().getPackage().getImplementationVersion(). If it can't find > the version it will eventually just give up and not do the database check. > The problem currently is if it doesn't find the version, it will also check > its parent's class version. The parent is java.lang.Object which will return > the java version (for example 1.6.0_43). It doesn't seem like we would > really want to ever try the JDK version as our code version, so this patch it > to just effectively remove that check. > > > Diffs > > - engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java > (f001bf7) > > View Diff <https://reviews.apache.org/r/14231/diff/> >
