db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: PersistentFields per class descriptors. was [RFC] Using java.lang.reflect.Proxy
Date Mon, 15 Mar 2004 14:09:13 GMT
Hi Thomas,

Thomas Dudziak wrote:
> 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).

hmm, ok so we need both possibilities to define PersistentFieldClass 
attribute filed- and class-descriptor level
and I fear the worst you want this feature for 1.0 ;-)

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

do we need this? One reason is that we do not separate metadata 
properties and functionality/service methods in metadata classes.

> some of the accessors have
> other names than the properties they represent;

yes, this should be refactored before 1.1

> there are values where a
> runtime change is not well supported, etc.)

I think this is really important for 1.0.
All these known issues should be noted in the release-notes.
Can you list the (most important) properties of class-/field-descriptor 
who don't support runtime changes?

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

I agree. But what are the alternatives and who will be willing to do 
this changeover?


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