RE: Choose columns to update
Hello Armin, we went for this approach. We have two descriptor repositories now, describing the same tables and referring to the same classes. The only issue is: The update of the one object (using descriptor repository 1) and the insert of the new object (using descriptor repository 2) have to occur within one transaction (naturally). To achieve this, we added the method setDescriptorRepository(DescriptorRepository descriptorRepository); to the PersistenceBroker interface. Now we can change the descriptor repository whenever required. It works so far, but we're not sure if this has other impacts. Is this a safe solution? What about officially adding the above method to the PersistenceBroker interface? Or better: are there plans to support updating only specific columns? I can imagine many users would want this, just think of tables with many and/or large columns and you want to update only one (perhaps in a batch-job...). Thanks for help, Norbert. -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 14:09 To: OJB Users List Subject: Re: Choose columns to update Hi, don't know if this will help you. With MetadataManager you can handle different metadata repositories (on per thread base), thus it's possible to have different ClassDescriptor for the same class (e.g. one with all fields, one with special fields). regards, Armin On Thu, 9 Oct 2003 13:07:10 +0200, <[EMAIL PROTECTED]> wrote: > Thanks for your reply. > > Could you please give me a hint how to achieve this anyhow? > We're planning a dirty workaround: Having a class with a static method > called by PersistenceBroker store(Object, ObjectModification) after > retrieving the class descriptor. > That method clones and modifies the affected class descriptor as desired, > depending on the object processed. The risk: If somewhere in the > framework > the class descriptor is not passed as parameter but instead looked up > from > the repository again, we're lost. > > How safe is this approach? Any other idea is highly appreciated. > > Thanks, > Norbert. > > > -Original Message- > From: Charles Anthony [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 09. Oktober 2003 12:04 > To: 'OJB Users List' > Subject: RE: Choose columns to update > > > >> -Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >> Sent: 09 October 2003 11:01 >> To: [EMAIL PROTECTED] >> Subject: Choose columns to update >> >> >> Hi all, >> >> I need to tell OJB which columns to update when persisting an object >> (instead of updating all mapped fields). Can anybody please >> tell me how to >> do this? > > Hi, > > I'm sorry no-one replied before. > > In short, this is not currently possible with OJB. > > I have a sneaking suspicion that this is *not* a trivial thing to do; as > you > may have noticed from the list, the developers are currently trying to > work > towards a 1.0 release in the near future (maybe via an rc5) - such a > substantial feature request would be unlikely to make into a release in > the > near future. > > Of course, I may be talking complete rubbish - in which case one of the > committers should respond - but I thought I'd reply just so you don't > think > we are ignoring you on purpose. > > Cheers, > > Charles. > > > This email and any attachments are strictly confidential and are intended > solely for the addressee. If you are not the intended recipient you must > not disclose, forward, copy or take any action in reliance on this > message > or its attachments. If you have received this email in error please > notify > the sender as soon as possible and delete it from your computer systems. > Any views or opinions presented are solely those of the author and do not > necessarily reflect those of HPD Software Limited or its affiliates. > > At present the integrity of email across the internet cannot be > guaranteed > and messages sent via this medium are potentially at risk. All liability > is excluded to the extent permitted by law for any claims arising as a > re- > sult of the use of this medium to transmit information by or to > HPD Software Limited or its affiliates. > > > > - > 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]
Re: Choose columns to update
Hi, Have you try to "simply duplicate" 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); ... 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
Re: Choose columns to update
Hi, don't know if this will help you. With MetadataManager you can handle different metadata repositories (on per thread base), thus it's possible to have different ClassDescriptor for the same class (e.g. one with all fields, one with special fields). regards, Armin On Thu, 9 Oct 2003 13:07:10 +0200, <[EMAIL PROTECTED]> wrote: Thanks for your reply. Could you please give me a hint how to achieve this anyhow? We're planning a dirty workaround: Having a class with a static method called by PersistenceBroker store(Object, ObjectModification) after retrieving the class descriptor. That method clones and modifies the affected class descriptor as desired, depending on the object processed. The risk: If somewhere in the framework the class descriptor is not passed as parameter but instead looked up from the repository again, we're lost. How safe is this approach? Any other idea is highly appreciated. Thanks, Norbert. -Original Message- From: Charles Anthony [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 12:04 To: 'OJB Users List' Subject: RE: Choose columns to update -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 09 October 2003 11:01 To: [EMAIL PROTECTED] Subject: Choose columns to update Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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]
RE: Choose columns to update
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]
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]
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]
RE: Choose columns to update
Thanks for your reply. Could you please give me a hint how to achieve this anyhow? We're planning a dirty workaround: Having a class with a static method called by PersistenceBroker store(Object, ObjectModification) after retrieving the class descriptor. That method clones and modifies the affected class descriptor as desired, depending on the object processed. The risk: If somewhere in the framework the class descriptor is not passed as parameter but instead looked up from the repository again, we're lost. How safe is this approach? Any other idea is highly appreciated. Thanks, Norbert. -Original Message- From: Charles Anthony [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 09. Oktober 2003 12:04 To: 'OJB Users List' Subject: RE: Choose columns to update > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 09 October 2003 11:01 > To: [EMAIL PROTECTED] > Subject: Choose columns to update > > > Hi all, > > I need to tell OJB which columns to update when persisting an object > (instead of updating all mapped fields). Can anybody please > tell me how to > do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - 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]
RE: Choose columns to update
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: 09 October 2003 11:01 > To: [EMAIL PROTECTED] > Subject: Choose columns to update > > > Hi all, > > I need to tell OJB which columns to update when persisting an object > (instead of updating all mapped fields). Can anybody please > tell me how to > do this? Hi, I'm sorry no-one replied before. In short, this is not currently possible with OJB. I have a sneaking suspicion that this is *not* a trivial thing to do; as you may have noticed from the list, the developers are currently trying to work towards a 1.0 release in the near future (maybe via an rc5) - such a substantial feature request would be unlikely to make into a release in the near future. Of course, I may be talking complete rubbish - in which case one of the committers should respond - but I thought I'd reply just so you don't think we are ignoring you on purpose. Cheers, Charles. This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Choose columns to update
Hi all, I need to tell OJB which columns to update when persisting an object (instead of updating all mapped fields). Can anybody please tell me how to do this? Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
