Bug 104351 - com.arsdigita.cms.populate.PopulateSuite leaves data in the database
Summary: com.arsdigita.cms.populate.PopulateSuite leaves data in the database
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: domain   
(Show other bugs)
Version: nightly
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-13 01:13 UTC by Dennis Gregorovic
Modified: 2007-04-18 16:57 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 17:38:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dennis Gregorovic 2003-09-13 01:13:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716

Description of problem:
Scott Seago pointed out to me today that the
com.arsdigita.cms.populate.PopulateSuite junit suite leaves data in the database
after it has finished running.  

I thought it might be a simple fix of extending BastTestCase instead of
TestCase, as BaseTestCase automatically rolls back the transaction when it is done.

However, the underlying CMS population code does its own transaction management
and commits.  So, the fix will involve refactoring the population code to allow

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run ant -Djunit.suite=PopulateSuite.class runtests

Actual Results:  about 1000 content items are added

Expected Results:  no content items are left in the database

Additional info:

Comment 1 Bryan Che 2003-09-15 15:37:06 UTC
capturing irc chat about this issue:

<scott> PopulateTest.java commits changes to the DB rather than rolling back, so
after "ant runtests" I've got 1000 extra ContentItems in the database
<bryanche> scott: I suggest not running that test then (I didn't write it).  the
data population code has to commit after every transaction because in its normal
use-case, for populating servers, not committing slows down the population a lot
<scott> bryanche: yeah. I figured that (hence the manual transaction management
in PopulateContent). but it ought to be safe to run the tests against a real db.
perhaps there should be a way to run PopulateContent without internal commits
(only used by the unit tests)
<bryanche> that wouldn't provide a realistic publishing test, though
<bryanche> the timings would be artificially slow
<bryanche> due to not committing
<bryanche> best solution is to delete the content after it's created
<scott> yes, that would be better :-)
<bryanche> so, there probably needs to be a cleanup step after the test is run
<bryanche> but that test doesn't make much sense for you to run anyway, because
it's testing performance of publishing
<scott> bryanche: right. I'm not really getting much out of this particular
test, but in terms of a general sanity check, I was running all tests on my
branch to make sure I didn't unexpectedly break anything that's not already broken
<bryanche> ok

Comment 2 Jon Orris 2006-09-05 17:38:02 UTC
Closing old tickets

Note You need to log in before you can comment on or make changes to this bug.