> Thomas wrote:
> Rick Sanderson wrote:
> > Is there a way to overwrite the setting from
> > OJB.properties (DefaultImpl or PropertyImpl)
> > on a field by field basis? (I could not find
> > it in the DTD)
>
> No, it's a global setting, you are expected to choose one approach for
> all your persistent classes.
>
>
> > If not, would you be interested in an implementation
> > that does it? To use OJB effectively, I will need
> > this flexibility.
>
> You are the first to ask for this feature. Why is it so important for you?
The fact that we are able to choose an approach for an entire application
indicates that there are different scenarios best suited to one
or the other. Why couldn't these different scenarios appear
<em>within</em> an application?
More specifically, please allow me to use an example:
class Item {
private ItemCategory _category;
/** used only by OJB -- I wish this were not needed */
private int _categoryID;
private Money _price;
public void setCategory( ItemCategory cat ){
_category = cat;
}
public ItemCategory getCategory(){
return _category;
}
public void setPrice( Money price ){
_price = price;
}
public Money getPrice(){
if ( _price==null ) {
_price = new Money();
}
return _price;
}
public void setPriceAmount( long amount ){
getPrice().setAmount( amount );
}
public setPriceCurrency( String curr )
getPrice().setCurrency( Currencies.get( curr ) );
}
// likewise for getters.
}
For this class, the DB table will have a column for currency, and
another for amount, but the class does not have such members (it uses
Money instances instead). In this case, OJB needs to use
the "property" method.
The "_categoryID" field is only an artifact of the OJB persistence,
and so getter/setter is not appropriate. Here the "default" method is
the best of all evils.
The above example serves to illustrate our discussion. In practise, I
might consider some other mechanism (perhaps extend the "RowReader") that
reads the currency and amount from the resultset, creates a Money, and
simply calls setPrice( Money ) on the Item instance.
In general, I envision using the "default" field descriptor for
either simple classes and/or for attributes that should not have public
access. Then using the "bean property" field descriptor for cases
where public access makes sense and/or business logic needs to be applied
to data coming to/from the datasource.
> If you contribute an implementation for this feature I will at least
> include your solution in our contributions package.
I would be surprised if other OJB users did not find such
a feature useful. Just IMHO. I will look into it though. Thanks.
Regards,
/rick.
>
> cheers,
> Thomas
>
>
> >
> > /rick.
> >
> > "Outside of a dog, a book is a man's best friend. Inside of
> > a dog, it's too dark to read."
> > -- anon
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Thomas Mahler [mailto:thma@;apache.org]
> >>Sent: Tuesday, November 12, 2002 1:28 PM
> >>To: OJB Users List
> >>Subject: Re: which attribute access behavior is correct?
> >>
> >>
> >>Hi Rick,
> >>
> >>this is very easy:
> >>
> >>OJB.properties determines which PersistentField implementation is used.
> >>0.9.7 defaults to PersistentFieldPropertyImpl (getter/setter)
> >>CVS HEAD defaults to PersistentFieldDefaultImpl (direct field access)
> >>
> >>please check OJB.properties for details.
> >>
> >>cheers,
> >>Thomas
> >>
> >>"Ask not what I can do for you. Ask what you can do for me."
> >> - Jerry Seinfeld
> >>
> >>Rick Sanderson wrote:
> >>
> >>>Using 0.9.7, OJB was recognizing class fields by getter/setter only.
> >>>It would report an error when only a member existed, as follows:
> >>>
> >>>[org.apache.ojb.broker.accesslayer.JdbcAccess] ERROR:
> >>>PersistenceBrokerException
> >>> during the execution of materializeObject: Error creating
> >>
> >>PersistentField:
> >>
> >>> com.enservia.entour.product.Product, categoryID
> >>>Error creating PersistentField: com.enservia.entour.product.Product,
> >>>categoryID
> >>>java.lang.reflect.InvocationTargetException
> >>> at
> >>
> >>sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> >>
> >>> ...
> >>>Caused by: org.apache.ojb.broker.metadata.MetadataException: Can't find
> >>>property categoryID in com.enservia.entour.product.Product
> >>> at
> >>>
> >>
> >>org.apache.ojb.broker.metadata.PersistentFieldPropertyImpl.findPro
> >>pertyDescr
> >>
> >>>iptor(Unknown Source)
> >>> at
> >>>
> >>
> >>org.apache.ojb.broker.metadata.PersistentFieldPropertyImpl.<init
> >(Unknown
> >>
> >>>Source)
> >>> ... 16 more
> >>>
> >>>In my class Product, I do have a private (tried public) member called
> >>>categoryID.
> >>>If I add getter/setter, it works.
> >>>
> >>>I then updated to the source from cvs (version 0.9.8). The
> >>
> >>absolute reverse
> >>
> >>>is true.
> >>>OJB now only recognizes member variables in the class, and not
> >>>getters/setters.
> >>>When only getter/setters appear in the class, an error very
> >>
> >>similar to the
> >>
> >>>above results.
> >>>
> >>>As Seinfeld might say... What's up with that?
> >>>
> >>>Since I can find no other posts on the mailing lists on this
> >>
> >>subject, I fear
> >>
> >>>I have some kind of invalid setup, but I can't for the life of
> >>
> >>me figure out
> >>
> >>>what it is.
> >>>
> >>>/rick.
> >>>
> >>>
> >>>--
> >>>To unsubscribe, e-mail:
> >>
> >><mailto:ojb-user-unsubscribe@;jakarta.apache.org>
> >>
> >>>For additional commands, e-mail:
> >>
> >><mailto:ojb-user-help@;jakarta.apache.org>
> >>
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
<mailto:ojb-user-unsubscribe@;jakarta.apache.org>
>>For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
>>
>
>
> --
> To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
