db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: Problem: Copy field values
Date Mon, 14 Mar 2005 21:02:31 GMT
i would much prefer the sql types for the 2nd level cache, and not make 
the 2nd level cache even an instance of ObjectCache, but give it its 
own interface (or accept any JCache style interface, which is basically 
a map).

-brian

On Mar 14, 2005, at 4:11 PM, 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.
> another approach could be to demand the mutable field-types have to be 
> serializable, this is imo not a big restriction.
> 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