Reduce Database Configuration Complexity - Proposal

Jay Shaughnessy jshaughn at redhat.com
Tue Jul 26 13:08:24 UTC 2011


Right, iirc, this was to allow for two databases so that running tests 
did not litter your dev db.  Prior to this we could only configure one 
db and so unit tests would typically ruin any data you had in the db you 
were using for dev/non-unit tests.

Having said that, I still tend to just use one db, duplicating the 
property settings. But the option is useful.

On 7/25/2011 5:56 PM, John Mazzitelli wrote:
> there was a reason we have two. we USED to have one, like you propose.
> We added the second.
>
> Ian knows more (we did this a few years ago) and it was mainly to
> support (IIRC) the ability to build releases in addition to being able
> to build dev builds.
>
> Wait for ips to come back and let him chime in on this.
>
> On 07/25/2011 05:27 PM, Stefan Negrea wrote:
>> 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
> _______________________________________________
> 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