Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1004518810.1260558138547.JavaMail.jira@brutus>
Date: Fri, 11 Dec 2009 19:02:18 +0000 (UTC)
From: "Myrna van Lunteren (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4038) On Z/OS store/access.sql fails with
 encryptionAES and encryptionDES
In-Reply-To: <1607137183.1233277199637.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren updated DERBY-4038:
--------------------------------------

    Attachment: DERBY-4038.diff_1

I'm attaching a patch that's a first attempt at converting this test.

I made a few changes where I figured the original test was doing something odd:
- as indicated in a previous comment, changed the sequence of events and updating of statistics in the partial row runtime statistics test case / fixture so it's now doing 4 different things. In doing so, there's no longer a duplicate index warning returned for a create index foo_cover statement; I assumed generating that error that wasn't the point of the test.
- changed the table in the CheckTable call in CS track 2241 test case from 'FOO' to B2441, assuming it was meant to check the table in the test case at hand.
- fixed up test case for cs track 2778:
  - made the create index work
  - fixed up the call using --derby-properties which for some reason gave a syntax error. 
- added a few select statements to CS495B (because then I could filter out
  a method to do the test 3 times)
- removed the call to procedure WAIT_FOR_POST_COMMIT as it didn't appear to
  be used anywhere.

I still need to:
- add it into store._Suite.java (and run suites.All to make sure this test doesn't interfere with other tests)
- hang the encryption scenarios around this one 
  (the access.sql test is run with encryption Algorithms AES,Blowfish,CFB,DES,ECB,OFB (through various encryption<ABC>.runalls) and DESede (through encryption all running storemats))

However, I'd like some input on this conversion so far.
- Was I misinterpreting the use of WAIT_FOR_POST_COMMIT? What would be the purpose of it?
- I added more questions in //TODOs within the converted test, the main of which are that it seems to me some of the test cases don't seem to do any checking of what they're supposed to check. For instance, the reclaim deleted rows doesn't seem to check anything is reclaimed.
- Are there obvious improvements to the flow of the test framework?


> On Z/OS store/access.sql fails with encryptionAES and encryptionDES
> -------------------------------------------------------------------
>
>                 Key: DERBY-4038
>                 URL: https://issues.apache.org/jira/browse/DERBY-4038
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.3.3.0
>         Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_25433 (JIT enabled, AOT enabled)
> J9VM - 20081105_025433_BHdSMr
> JIT  - r9_20081031_1330
> GC   - 20081027_AB)
> JCL  - 20081106_01
> $ pwd
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: access.diff, access.out, DERBY-4038.diff_1
>
>
> On Z/OS access.sql fails for encryptionAES and encryptionDES. The diff is big but I can't quite make out what the problem is. Maybe just a change of query plans.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.