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 Fri, 11 Mar 2005 13:58:26 GMT

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 

> ...
> 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?)


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

View raw message