Now I get your point.
There are currently two ways to handle this:
1. your solution (have two entity classes representing the same table)
2. Manipulate the ClassDescriptor of the entity class at runtime so that read only attributes are only present for read operations but not for store operations.
You could use a custom attribute to declare which attributes are read only. You could implement a litte manager that switches on/off attributes if they are marked as read-only.
A third way would be to ask us to implement it :-) But this would take a while as we have so many other things on the todo list already.
But if you write such a manager I'll integrate it into the distribution.
cheers,
Thomas
Bram Meijboom wrote:
Ah some explanation needed what my problem is..
ok, as far as i know the pb.store(bean) results in a statement like
update name_value set name='name', value='value' where id=1
where the bean has 2 attributes.
I use in my project a Stored Procedure to insert a new object in the
database(no way around it for all i know...)
and have values in my bean that are inserted by the sp, but have to be "read
only" in the java bean
so if i want to update other attributes the "read only" attributes are going
to be updated also what in my case is incorrect behaviour.
eg name is read only and value is updatable
class NameValue {
private int id;
private String name;
private String value;
}
with a basic mapping
<class-descriptor class="NameValue" table="name_value">
<field-descriptor id="1" name="id" column="id" jdbc-type="INTEGER"
primarykey="true" autoincrement="true" />
<field-descriptor id="2" name="name" column="name"
jdbc-type="VARCHAR" nullable="false" />
<field-descriptor id="3" name="value" column="value"
jdbc-type="VARCHAR" nullable="false" />
</class-descriptor>
so how do i make ojb "understand" that name is read only?
so if i create a facade with the following interface
public NameValueFacade {
public NameValue create(String name, String value) {
// use a stored procedure
}
// returns a collection of beans with the name's public Collection find(String name) {
// your basic querry with criteria code here
}
//only update the value attribute...
public void store(NameValue nameValue) {
// so how do i tell the broker that the name attribute is
not going to be updated?
pb.store(nameValue)
// the resulting update has to be something like
// update name_value set value='value' where id=1
}
}
greets
bram
-----Original Message-----
From: Mahler Thomas [mailto:thomas.mahler@;itellium.com]
Sent: Monday, November 11, 2002 3:30 PM
To: 'OJB Users List'
Subject: AW: read only attributes
PersistentFieldDefaultImpl is slower and PersistentFieldMaxPerformanceImpl
is faster than PersistentFieldPropertyImpl
cheers,
Thomas
-----Urspr�ngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:claudio.romano@;lindos.ch]
Gesendet: Montag, 11. November 2002 15:06
An: OJB Users List
Betreff: RE: read only attributes
Hi,
If I tell OJB not to rely on getter/setter method,
will it be slower or faster?
thanks,
Claudio
-----Original Message-----
From: Mahler Thomas [mailto:thomas.mahler@;itellium.com]
Sent: Monday, November 11, 2002 2:56 PM
To: 'OJB Users List'
Subject: AW: read only attributes
Hi Bram,
You can tell OJB to not rely on getter/setter methods, by enabling
PersistentFieldDefaultImpl in OJB.properties.
If you do this, your persistent objects won't need getter and setter methods
at all!
cheers,
Thomas
-------Urspr�ngliche Nachricht----- Von: Bram Meijboom [mailto:bram@;info.nl] Gesendet: Montag, 11. November 2002 14:48 An: [EMAIL PROTECTED] Betreff: read only attributesHi simple question, Is there a easy way to have read only attributes? I thought about making 2 beans, one with the read only attribute and one without and making the pb.store(ReadOnly bean) not public available... but it seem like a hack to me greets Bram -- 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>
-- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
