Norbert -- Have you considered utilizing the stored procedure support that's now available on OJB?
For each table, you would simply rely on the 'standard' OJB logic for handling insert and delete operations. For update operations, you would set up an update-procedure descriptor that identifies the stored procedure that would handle the update operation. In this stored procedure, you would do exactly what you describe below: Update the existing record as necessary and create a new record. Since the same pattern applies to all 80 tables, you could probably set up some sort of code generation process to create the update procedures for each of the 80 tables. Just a thought. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 8:37 AM To: [EMAIL PROTECTED] 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
