Reduce Database Configuration Complexity - Proposal

Charles Crouch ccrouch at redhat.com
Mon Jul 25 21:36:56 UTC 2011


If its any consolation iirc the situation was even worse before we had the two sets of settings.

Ian, did you work in this area? Comments on stefan's changes?

Thanks
Charles

----- Original Message -----
> Hello Everybody,
> 
> I have been working on BZ 7222298
> (https://bugzilla.redhat.com/show_bug.cgi?id=722298) to port dbreset
> to Oracle. During this work I got confused over data source
> configuration.
> 
> Currently there are two sets of settings (rhq.test.ds and rhq.dev.ds)
> for data source configuration (primarily used for unit tests). The two
> sets are almost identical (username, passsword, type-mapping), the
> main difference is db-name. Additionally, there is a flag used to
> switch between the two sets. And here is where the confusion starts...
> Not all the scripts use (or use correctly) the flag to switch between
> the settings. A lot of the scripts/tests only use rhq.test.ds (and
> completely ignore rhq.dev.ds or the flag). The original dbreset was
> not making full use of the settings either. At any single time, it is
> possible to use only one set.
> 
> My initial dbreset port was very confusing and complicated because
> there are so many settings. I had to take into account fall-back
> scenarios (when one setting was not defined for one profile but it was
> a for the other). So, I took a step back and looked at ways to
> simplify/improve this.
> 
> And here is my proposal:
> 1) Remove both rhq.dev.ds and rhq.test.ds; and remove the flag to
> switch between the two sets.
> 2) Consolidate everything into one set of settings - rhq.ds.
> 3) To use a different database for building/testing/resetting the db
> then just override rhq.ds (eg. -Drhq.ds.db-name=rhq_dev) at command
> line. Or better, create separate profiles in .m2/settings.xml and
> activate each profile as needed for maven builds.
> 
> Having only one set will:
> 1) make it easy to understand data source settings (only rhq.ds to
> configure)
> 2) reduce the code complexity (no fall-back, no flags to switch
> between settings).
> 3) make it easy to override the correct settings for your particular
> database configuration.
> 4) make new unit tests consistent and reduce the possibility to make
> mistakes.
> 
> Here is the branch with the changes I made for dbreset:
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=shortlog;h=refs/heads/stefan/dbreset
> 
> And here is the commit with most of the changes proposed for rhq.ds:
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commit;h=187643
> 
> 
> Any suggestions or input for my proposal? Is there a reason to keep
> two sets of tests? Are there any use cases that cannot be accomplished
> by profiles/settings override?
> 
> 
> Thank you,
> Stefan Negrea
> 
> Software Engineer
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list