Hi,
Have you try to "simply duplicate" class descriptor :
<class-descriptor class="A" table="A" refresh="true">
<field-descriptor id="1" name="id" column="ID" jdbc-type="BIGINT"
primarykey="true" autoincrement="true"/>
<field-descriptor id="2" name="field2" column="field2" jdbc-type="BIGINT"
access="readwrite"/>
<field-descriptor id="3" name="field3" column="field3" jdbc-type="VARCHAR"
access="readwrite"/>
<field-descriptor id="4" name="field4" column="field4" jdbc-type="BIGINT"
access="readonly"/>
<field-descriptor id="5" name="field5" column="field5" jdbc-type="VARCHAR"
access="readonly"/>
...
</class-descriptor>
used to materialize A objects and so, call your store methode on it after update
attribute like this :
instanceOfA.setField1(...);
instanceOfA.setField2(...);
pb.store(instanceOfA);
<class-descriptor class="AforInsert" table="A">
<field-descriptor id="1" name="id" column="ID" jdbc-type="BIGINT"
primarykey="true" autoincrement="true"/>
<field-descriptor id="2" name="field2" column="field2" jdbc-type="BIGINT"
access="readwrite"/>
<field-descriptor id="3" name="field3" column="field3" jdbc-type="VARCHAR"
access="readwrite"/>
<field-descriptor id="4" name="field4" column="field4" jdbc-type="BIGINT"
access="readwrite"/>
<field-descriptor id="5" name="field5" column="field5" jdbc-type="VARCHAR"
access="readwrite"/>
...
</class-descriptor>
used to create A objects like this :
instanceOfA=new AforInsert(field1,field2,field3 ...)
pb.store(instanceOfA);
----- Original Message -----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, October 09, 2003 2:37 PM
Subject: RE: Choose columns to update
Hi Ron,
thanks for your reply.
Setting the access property is not suitable, because for each modification a
client does, we have to update one record, and insert another one. The
update touches only 2 fields. The insert naturally has to write all fields.
Could be solved with 2 descriptors on the same table. But this behaviour is
generic for all our 80 tables. If we find a generic solution, we could save
a lot of 'useless' code.
Somehow the best solution would be if OJB includes only those attributes in
the update query which indeed were changed.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 09. Oktober 2003 14:19
To: [EMAIL PROTECTED]
Subject: RE: Choose columns to update
Norbert --
As far as excluding certain columns from an insert/update statement, setting
the 'access' property on an field-descriptor to 'readonly' will cause that
field/column to be excluded from any insert/update statement that is
generated by ojb.
As far as getting OJB to issue an insert statement in lieu of an update
statement, the PersistenceBroker interface defines two methods for storing
objects:
public void store(Object obj);
public void store(Object obj, ObjectModification modification);
If you call the second version of this method and pass
org.apache.ojb.broker.util.ObjectModificationDefaultImpl#INSERT for the
'modification' argument, then ojb will issue an insert statement.
Ron Gallagher
Atlanta, GA
[EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 10:13 AM
To: [EMAIL PROTECTED]
Subject: Choose columns to update
Hi all,
we use OJB1.0 RC4 against a DB2.
We want to tell OJB which columns should be included in the update statement
instead of updating all of them. The columns to update have the same name
and definition in all the tables.
Detailled information:
We have tables with many columns. Some columns hold only 'technical'
information like lastupdate timestamp and occur in each table. Whenever a
record is modified, we *insert* a new one and update these technical
attributes of the previously valid record (i.e. we are historizing the
changes). The tables also have many indexes. Therefore, updates on all
fields are costy (beside the bigger effort to build the query, higher
network traffic to the database and the obvious bigger overhead for the
database, it seems that these non-affected fields also cause costy index
calculations ond the database if incuded in the update).
What we actually need would be another descriptor for each table which
describes only this subset of columns to update. But this would cause many
more descriptors and classes. Because all information is already in the
objects and in the descriptors, we do not consider this as a solution.
The only thing we need is to tell OJB not to include every column in the
update statement (respectively which columns to include, similar to a
ReportQuery). How to do this?
Thanks in advance,
Norbert.
---------------------------------------------------------------------
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]
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 06/10/2003
