db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Problem: Copy field values
Date Mon, 14 Mar 2005 21:05:51 GMT
Jakob Braeuchi wrote:
> hi armin,
> 
> i must admit that i did not like the idea of using sqlType at the first 
> look... because we mix caching functionality with sql stuff.
> but after a little debugging (just trying to understand the code) i 
> think it may be the easiest way to go, simply because we now all 
> possible field types.

yep, keep in mind the FieldConversion stuff. If we copy on java field 
level (before java-->sql field conversion) instead of sql field level we 
don't know how to copy a field if a field-conversion (e.g. int[] to 
String) was used - ok, we can use reflection, but this will be costly to 
do if complex field objects are used.
As Brian mentioned we can think about extending FieldConversion with a 
#copyField and #equals(obj1,obj2) method in OJB 1.1. But this could 
cause problems in the TLCache when different class-descriptor with 
different field-conversion for the same class are used (improbably by 
possible).

> another approach could be to demand the mutable field-types have to be 
> serializable, this is imo not a big restriction.

agree, think we should use the best performing solution:
- java level with reflection + serializeable fields
- java level with reflection + field-conversion#copy method
- sql level

regards,
Armin







> jakob
> 
> Armin Waibel schrieb:
> 
>> Hi all,
>>
>> today I checked in some changes and a new interface 
>> ...metadata.FieldType which help to copy and compare field values of 
>> persistent objects. This is used in ObjectCacheTwoLevelImpl to copy 
>> persistent objects and it's used in odmg.ObjectEnvelope to take an 
>> image of a locked object.
>>
>> The basic problem is how can we make an image or a copy of a 
>> persistent object, how to copy the object fields?
>>
>> On OJB java-field-type level a field (of a persistent class) could be 
>> all kind of class, because the user can declare a field-conversion in 
>> the field-descriptor, thus we don't know the field type in the 
>> persistent object.
>> So it's not possible to image/copy field values on this level, because 
>> the fields don't have to implement Serializeable or Cloneable.
>>
>> If we convert the fields to the sql-field-type using the javaToSql 
>> field-conversion we know the type of the field (performance issue when 
>> using complex field-conversions?), because this is declared in the 
>> field-descriptor and we are using the jdbc type / java type mapping of 
>> the JDBC specification:
>> VARCHAR --> String
>> VARBINARY --> byte[]
>> DATE --> Date
>> ...
>> Now we know the type of the field. All possible types, FieldType 
>> implementation classes, are defined in the new class 
>> metadata.FieldTypeClasses as static inner classes.
>> We differ two base types:
>> - Immutable, like String, Integer, Long,...
>> - Mutable, like Date, Timestamp, byte[],...
>> To copy immutable types is easy, use the field value itself. 
>> Problematic are mutable types (copy values, compare values) and 
>> mutable types that behave like immutable types, because we can't 
>> handle them (like Blob, Clob, Struct,...).
>> How should we handle these "exotic" types?
>>
>>
>> regards,
>> Armin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message