Hi Markus,
The problem here is that the field in the temporary table not exactly the same as the one in the original table.
Some databases provide ways to copy the exact field info from the original table.
For instance DB2 has operator "LIKE":
DECLARE GLOBAL TEMPORARY TABLE session.TL_CMP3_EMPLOYEE LIKE CMP3_EMPLOYEE ON COMMIT DELETE ROWS NOT
If something like that is available in MaxDB then use it by overriding getCreateTempTableSqlBodyForTable method.
Otherwise add some reasonable default sizes to FieldTypeDefinitions set in buildFieldsType method:
currently used (in my older copy MaxDBPlatform at least) line:
fieldTypeMapping.put(String.class, new FieldTypeDefinition("VARCHAR"));
means that FieldTypeDefinition is not required to have size.
Substitute it with something more reasonable, may be:
fieldTypeMapping.put(String.class, new FieldTypeDefinition("VARCHAR", 255));
You'll probably need to change some other types, too:
In your other message your asking why EMP_ID is built as INTEGER in temp. table -
it's because of id attribute is of type Integer in Employee,
and the following line in MaxDBPlatform:
fieldTypeMapping.put(Integer.class, new FieldTypeDefinition("INTEGER", false));
Just make sure to map Long and Integer classes to db field types that could be compared.
You can find all sorts of examples of FieldTypeDefinition on other database platforms.
Could you please state other problems that seem to br related with UpdateAll and DeleteAll in general and temporary tables in particular.
Thanks,
-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
>