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!
- application/pkcs7-signature attachment: smime.p7s