Hi Markus,
I am currently fixing another UpdateAll bug in essentials.
As soon as I am done (hopefully by tomorrow) I'll start looking at the temp. tables problems you've encountered.
I apologize for the delay,
Andrei
----- Original Message -----
From: "Markus KARG" <markus.karg_at_gmx.net>
To: "Tom Ware" <tom.ware_at_oracle.com>; <dev_at_glassfish.dev.java.net>
Cc: "Andrei Ilitchev" <andrei.ilitchev_at_oracle.com>
Sent: Saturday, November 18, 2006 1:06 PM
Subject: Re: Issues with entity-persistence-tests on MaxDB
> Tom,
>>>>> (2) Char value too long
>>>>> Testcase: testReadTransactionIsolation_UpdateAll took 0,052 sec
>>>>> Caused
>>>> This looks like it is related to the issue above. We should take a
>>>> look at all the SQL for the Delete query that is executed (including
>>>> the creation of the temporary table). To do that, you may have to run
>>>> the EntityManagerJunitTestSuite by itself with logging on and add some
>>>> indicators of where the test begins and ends.
> I have debugged that test case with FINEST logging enabled and found out
> that the reason is quite simple. Actually I propose the following to be
> a bug of TopLink and I hope that you will be so kind to fix that (it is
> outside of MaxDB and far beyond my knowledge about TopLink internals):
>
> When the test runs, the log posts that the following two code lines get
> executed (among others):
>
> CREATE TABLE TEMP.$CMP3_EMPLOYEE (EMP_ID INTEGER NOT NULL, VERSION
> INTEGER, L_NAME VARCHAR, PRIMARY KEY (EMP_ID))
> INSERT INTO TEMP.$CMP3_EMPLOYEE (EMP_ID, VERSION, L_NAME) SELECT
> t0.EMP_ID, (t0.VERSION + 1), 'New' FROM CMP3_EMPLOYEE t0, CMP3_SALARY t1
> WHERE ((t0.F_NAME LIKE 'testReadTransactionIsolation') AND (t1.EMP_ID =
> t0.EMP_ID))
>
> As you can read from that code lines, there is a column created with
> VARCHAR type but no size specified. MaxDB in that case assumes an
> implied size of 1 character.
> Then the following INSERT tries to put the word 'New' (= size of 3) into
> that column.
> Unfortunately MaxDB is not behaving like other databases: It does not
> truncate the string value, but instead throws an SQLException that the
> value is too long (I tried it out with a simple test program).
>
> So the solution is to tell TopLink to provide the correct size but no to
> rely on a specific default or specificat behaviour like automatic
> truncation. Since MaxDB is right (the value REALLY is longer than the
> target column's width), I am rating this as a bug of TopLink.
>
> Since I am not a TopLink guru, I would really appreciate if you could
> fix that. A lot of test cases crash due to that reasons when running on
> MaxDB.
>
> Thanks a lot!
> Markus
>