db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Problem: Copy field values
Date Fri, 11 Mar 2005 16:37:12 GMT
hi all,

imo we should first exactly define the purpose of the 2nd level cache 
before we can decide which types to cache.

if the 2nd level cache is mainly used to increase performance then i 
think caching of lobs etc. does not make sense. what do we cache if an 
object has lob-fields ? all other fields, or do we not cache the whole 
object at all ?

if the 2nd level cache is used to optimize sql-updates we should store 
as many types as possible.

just my 0.02 chf


Brian McCallister schrieb:
> On Mar 10, 2005, at 3:57 PM, Armin Waibel wrote:
>> 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.
> Backwards incompatible option: provide a copy function on field 
> conversions. Provide an AbstractFieldConversion which keeps a flat 
> fieldwise copy of the custom object, but can be replaced by a more 
> intelligent version. I like this option less than the next...
>> 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
> Caching the jdbc type makes the most sense to me, and going ahead and 
> doing the conversion. I don't think the second level cache should be 
> keeping entity instances around, just the sql values. Running them 
> through the conversion process is still much cheaper than hitting the db.
>> ...
>> 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?
> For Date and its ilk, and arrays, providing special handling for them is 
> reasonable. Arrays of immutables will be a pain, but then so is caching 
> of LOB's (should we even cache LOB's?)
> -Brian
> ---------------------------------------------------------------------
> 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

View raw message