Bug 104351 - com.arsdigita.cms.populate.PopulateSuite leaves data in the database
com.arsdigita.cms.populate.PopulateSuite leaves data in the database
Status: CLOSED WONTFIX
Product: Red Hat Enterprise CMS
Classification: Retired
Component: domain (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-12 21:13 EDT by Dennis Gregorovic
Modified: 2007-04-18 12:57 EDT (History)
0 users

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


Attachments (Terms of Use)

  None (edit)
Description Dennis Gregorovic 2003-09-12 21:13:58 EDT
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
rollbacks.




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


How reproducible:
Always

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

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 11:37:06 EDT
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 13:38:02 EDT
Closing old tickets



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