persistence@glassfish.java.net

Re: Should not we also have fieldTypeMappings for byte[] and char[]

From: Tom Ware <tom.ware_at_oracle.com>
Date: Fri, 27 Jan 2006 10:59:00 -0500

I agree with Craig.

I believe this change will only affect our table creation logic, but
when this issue is addressed that should be confirmed.

-Tom

Craig L Russell wrote:

> Hi Pramod,
>
> A lot of this discussion is too arcane for me to track. I have a
> simple question.
>
> Is there any conversion of the data written in case of a byte[ ]? I'd
> like not.
>
> I'd like for the bits to be written exactly as the user put them into
> the byte[ ] with no serialization or other transformation of the data.
> That is, to use setBytes to write them to the driver.
>
> Thanks,
>
> Craig
>
> On Jan 26, 2006, at 11:12 AM, Pramod Gopinath wrote:
>
>> Hi Tom
>> I am fine with you making the changes. I had one additional
>> observation. This has to do with
>> ConversionManager.getObjectClass(Class javaClass)
>>
>> This method assumes that a byte[] would return isPrimitive() to be
>> true. This is invalid.
>>
>> Thanks
>> Pramod
>>
>>
>>
>> Tom Ware wrote:
>>
>>> Hi Pramod,
>>>
>>> It looks to me like making the changes to add byte[] and char[]
>>> make sense. As long as your testing works for these changes that
>>> should be fine.
>>>
>>> Theoretically making the changes for int[], long[] etc.. to produce
>>> a Blob is also OK. Making these changes will require a great deal
>>> of interoperability testing to make sure JDBC handles these mappings
>>> for the majority of our supported databases.
>>>
>>> -Tom
>>>
>>> Pramod Gopinath wrote:
>>>
>>>> Hi Tom/Gordon
>>>>
>>>> In the method buildFieldTypes() of the database platforms we
>>>> currently have definitions for Byte[] and Character[]. Shouldn't we
>>>> also have definitions for byte[] and char[]. So currently if the
>>>> user defines a field that is byte[] we are incorrectly creating a
>>>> VARCHAR(255) field for it.
>>>>
>>>> For e.g. looking at DB2Platform.buildFieldTypes() we currently have
>>>>
>>>>
>>>> fieldTypeMapping.put(Byte[].class, new
>>>> FieldTypeDefinition("BLOB", 64000));
>>>> fieldTypeMapping.put(Character[].class, new
>>>> FieldTypeDefinition("CLOB", 64000));
>>>>
>>>> should we not also have
>>>>
>>>> fieldTypeMapping.put(byte[].class, new
>>>> FieldTypeDefinition("BLOB", 64000));
>>>> fieldTypeMapping.put(char[].class, new
>>>> FieldTypeDefinition("CLOB", 64000));
>>>>
>>>>
>>>>
>>>> Also in EJBAnnotationsProcessor.processLob() we are currently
>>>> setting the fields to be of type java.sql.Clob and java.sql.Blob
>>>> but none of the database platforms have any definitions for
>>>> java.sql.Blob or Clob.
>>>> So there is a bug currently, where a user field defined as
>>>> @Lob
>>>> public byte[] getPic() { return pic; }
>>>>
>>>> gets created as VARCHAR(255) which is wrong. This should be created
>>>> as BLOB(<some size>). I am using DERBY database.
>>>>
>>>>
>>>> Once the above change (byte[] and char[] is made) the code in
>>>> EJBAnnotationsProcessor.processLob would change to read
>>>>
>>>> if (MetadataHelper.isValidClobType(referenceClass)) {
>>>> mapping.setFieldClassification(char[].class); }
>>>> else if (MetadataHelper.isValidBlobType(referenceClass)) {
>>>> mapping.setFieldClassification(byte[].class);
>>>>
>>>>
>>>> Additionally the code does not account for arrays of other
>>>> primitive types like int[], long[] ... etc. Should they not be
>>>> treated as Blobs too ?
>>>>
>>>>
>>>> What do U guys think ?
>>>>
>>>> Thanks
>>>> Pramod
>>>>
>>>>
>>>>
>>>>
>>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell_at_sun.com
>
> P.S. A good JDO? O, Gasp!
>
>

-- 
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com