Hi Markus,
The code that deals with "NOT NULL" is in
FieldDefinition.appendDBString(). Here is the if statement:
if (shouldAllowNull() && fieldType.shouldAllowNull()) {
session.getPlatform().printFieldNullClause(writer);
} else {
session.getPlatform().printFieldNotNullClause(writer);
}
Does your platform have an implementation of printFieldNullClause()?
-Tom
Markus KARG wrote:
>Tom,
>
>here is an essential update. Forget the email of yesterday. ;-)
>
>
>>Hi Markus,
>> In the mean time, I think your best strategy is to temporarily
>>change the test models to use TABLE sequencing. I believe you will
>>have to change 4 classes:
>>
>>
>I have implemented native sequences on SQLAnywhere by using
>autoincremented columns plus reading the last used value later (as
>SybasePlatform does). It works well. Not only the native sequence tests
>ALL pass without error (!), also all the other errors are gone now! Wow,
>what a difference: Only 7 errors plus 7 faults left over! Some of the
>errors can be fixed without your help I think, since I can copy my
>solution from MaxDBPlatform. :-)
>
>I have one question I hope you can answer me:
>
>How to tell TopLink to add "NULL" tag (I mean the "NULL IS ALLOWED TAG",
>not the "NOT NULL TAG")?
>
>I have mapped java.lang.Boolean to "BIT" sql type. The problem is:
>SQLAnywhere implies "NOT NULL" with the type "BIT" unless explicitely
>writing "BIT NULL" (yes, I know, this is totally strange since typically
>SQL works the other way: it assumes "BIT NULL" unless you write "BIT NOT
>NULL"). So I need to tell TopLink that it must add "NULL ALLOWED"
>explicitely. I thought that this will be done when writing "new
>FieldTypeDefinition("BIT", false, false)" instead of "new
>FieldTypeDefinition("BIT", false, true)" (or its simpler form: "new
>FieldTypeDefinition("BIT", false)"). Unfortunately, as I can read from
>the test log, TopLink ignores the third parameter: It does never add
>"NULL ALLOWED" to the CREATE TABLE, independent of the third parameter
>being true, false or omitted. Is that a TopLink bug, or is something
>missing in my platform implementation? Actually I can work around by not
>mapping to "BIT" but to "TINYINT", which suppresses the error but
>actually uses two bytes for a single bit then, what is not very smart.
>
>Thanks a lot!
>Markus
>
>