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 directory. 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. >> > >
