db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.gmd.de>
Subject Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Date Mon, 15 Mar 2004 12:31:57 GMT
On Mon, 15 Mar 2004, Armin Waibel wrote:

> Hi Leandro,
> 
> I agree that PersistentFieldClass configuration isn't flexible today 
> (setting the standard class in OJB.properties may not fit all 
> application ranges).
> 
> But I don't like setting PersistentFieldClass on class-descriptor level, 
> because PersistentFieldClass is associated with field-descriptor/field 
> attribute - it's a field-descriptor attribute.
> E.g. if a user use java bean style setter/getter in all persistent 
> capable classes and PersistentFieldIntrospectorImpl as standard 
> PersistentFieldClass (set in OJB.properties). But for PK/FK fields he 
> doesn't want to define setter/getter. Then it would be a useful 
> improvement to allow setting of PersistentFieldClass on field-descriptor 
> level (then user could specify PersistentFieldDirectAccessImpl for all 
> PK/FK fields and standard PersistentFieldClass, in this example 
> PersistentFieldIntrospectorImpl, for all other fields).
> 
> In future and if users request setting PersistentFieldClass on 
> class-descriptor level, it could be a "convenience setting" if users 
> don't want to define PersistentFieldClass on each field-descriptor.
> But I don't recommend this, because it will make handling of metadata 
> runtime changes more and more complex (e.g. user change 
> PersistentFieldClass on class-descriptor at runtime).
> 
> -1, allow setting of PersistentFieldClass on class-descriptor level.
> Or is this setting imperative to make something work?

I agree and disagree.
I disagree because I believe this is a desirable feature on both the class
and field level especially for fine-tuning (one class requires
bean-property access whereas other classes can do with direct field access
which is way faster) and situations where you don't want to expose fields
via getters/setters (and private accessors only because the field handler
needs them are somewhat awkward).
I agree that this would make metadata handling more complex, however as
there other issues with the metadata handling as it is (e.g. it does not
work standalone, i.e. without other OJB stuff; some of the accessors have
other names than the properties they represent; there are values where a
runtime change is not well supported, etc.), perhaps we should invest some
work in the metadata handling (and the parsing, IMO the XML metadata
parser is ugly and unflexible) for 1.1 ?

Tom


---------------------------------------------------------------------
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