db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-216) expand largeCodeGen.java test
Date Wed, 01 Feb 2006 21:53:15 GMT
I haven't followed the largeCodeGen test much, does it take an extremely
long time or need a lot of memory?  I am not sure what amount of time is
the cutover from not being appropriate in the nightly suite.  Otherwise
we should just have add it somewhere else.

I have run the large data test recently, and I think it took 6 hours and
17gb on a 1.8 laptop.  So far I have not made it through a whole suite
(basically I have only had overnight free on the machine and it has
not finished).  It would be nice if when this test succeeds if it
dropped it's tables so you would not be left with 17gb in the test

If anyone has the resources to run the suite repeatedly, that would
great.  It now will catch some serious blob/clob regressions we have
had in the past.

Kathey Marsden (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12364516 ]

> Kathey Marsden commented on DERBY-216:
> --------------------------------------
> I pulled the largeCodeGen test into the largeData suite.  I suppressed the exception
output for failed cases by default. It varies from run to run and jvm to jvm.  There is a
boolean PRINT_FAILURE_EXCEPTION that can be turned on for debugging.
> I am curious.  Is there anyone out there that runs the largeData test from time to time?
 What are the system requirements?
>>expand largeCodeGen.java test
>>         Key: DERBY-216
>>         URL: http://issues.apache.org/jira/browse/DERBY-216
>>     Project: Derby
>>        Type: Sub-task
>>  Components: Test
>>    Reporter: Kathey Marsden
>>the largeCodeGen test needs to be expanded to include other cases that genreate large
amounts of byte code. 
>>For example:
>>     large in clause
>>     large insert statement that inserts many rows
>>     sql statements with large constant values 
>>It is best if the verious tests just use a variable that can be bumped higher and
higher for testing and if individual cases are isolated.
>>Possible approaches, think of ways to make sql statements really big that will take
different code paths.
>>Look in the code for instances of statementNumHitLimit and create cases that pass
through that code.  Those cases may pass but the hope is to get rid of these calls in favor
of splitting  the code in a centralized way, so add the tests to largeCodeGen even if they
don't fail.

View raw message