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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
