Reduce Database Configuration Complexity - Proposal

John Sanda jsanda at redhat.com
Tue Jul 26 13:44:54 UTC 2011


I make extensive use of both dbs. Provided we can preserve the existing 
functionality, I am all for reducing complexity.

On 7/26/11 9:08 AM, Jay Shaughnessy wrote:
> 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
>>
> _______________________________________________
> 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