Best practice for entity update.
I wanted to ask a question about the best way to prevent users overwriting each others changes when updating the database. If you use the simplest way IntakeTool intake = (IntakeTool) context.get(ConstSpr.INTAKE_STRING); Group group = intake.get(ConstSpr.INTAKE_SPRSA_CONTRACT,IntakeTool.DEFAULT_KEY); SprsaRsaContract sprsa = new SprsaRsaContract(); group.setProperties( sprsa ); sprsa.save(); You can over right another users changes to the database. I have decided to stuff the torque object used to build the form into the users temporary storage and then when the user submits the form I retreive it and do something like : Criteria whereCriteria = SpscmSalesCompanyPeer.buildCriteria(this); Criteria updateCriteria = SpscmSalesCompanyPeer.buildCriteria(newValues); SpscmSalesCompanyPeer.doUpdate(whereCriteria, updateCriteria); Then check to see how many rows were updated. Any suggestions for this would be appreciated. Thanks, Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Database independent error trapping.
I am wondering if there is a way to do database independent error trapping. For example on a table/object that has a unique key I just invoke the .save() method and and trap any exception. I look at the exception to see if it was a duplicate value in the unique column that caused the error and then explain this to the user in a friendly message. My problem is that I want the system to portable to different database so I do not want to do something like: eSql = (SQLException) t; if ( !eSql.getSQLState().equals(23505) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Best practice for entity update.
Hi! If it isn't possible to use a transaction connection you can use a timestamp column to verify if the row is changed in the database. Before saving the instance you can read the timestamp column from the DB and compare it with the timestamp that is set in your instance (this should be done in a short transaction during save()). bye Thoralf -Ursprüngliche Nachricht- Von: Christopher Thill [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 9. Februar 2007 12:46 An: Apache Torque Users List Betreff: Best practice for entity update. I wanted to ask a question about the best way to prevent users overwriting each others changes when updating the database. If you use the simplest way IntakeTool intake = (IntakeTool) context.get(ConstSpr.INTAKE_STRING); Group group = intake.get(ConstSpr.INTAKE_SPRSA_CONTRACT,IntakeTool.DEFAULT_KEY); SprsaRsaContract sprsa = new SprsaRsaContract(); group.setProperties( sprsa ); sprsa.save(); You can over right another users changes to the database. I have decided to stuff the torque object used to build the form into the users temporary storage and then when the user submits the form I retreive it and do something like : Criteria whereCriteria = SpscmSalesCompanyPeer.buildCriteria(this); Criteria updateCriteria = SpscmSalesCompanyPeer.buildCriteria(newValues); SpscmSalesCompanyPeer.doUpdate(whereCriteria, updateCriteria); Then check to see how many rows were updated. Any suggestions for this would be appreciated. Thanks, Chris - 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]
Please unblock the email from Torque-user@db.apache.org Turbine-user@jakarta.apache.org Velocity-user@jakarta.apache.org Thanks.
RE: Database independent error trapping.
Three or four years ago, I did some coding on a pre-Torque system that tried to deal with this issue. One major problem I remember is that there is no true standard for SQL error codes. And what standards there are don't seem to be implimented very well (or at all). To add to the confusion, the error codes are actually generated/interpreted by the JDBC layer and not the DB vendor. So, you can't just say MS SQL does it this way, you have to say MS's JDBC driver does it this way, Avinar's does it this way, jTDS does it this way, etc. I even found some variance in returne codes between driver versions by the same vendor. That said, what I ended up doing in my pre-Torque code was to write a bit of JDBC driver profiler code that ran when the system started up. This created the set of errors my app was concerned with, stored them away, and them my error checking code compared to these. I'm not sure this can be applied to Torque since to find the errors, your DB connect account rights have to be able to do thingslike create / delete tables, etc. that some security folks frown on. Hmm, I wonder if a new Torque 4 ToDo would be a bit of code that wraps any Torque exception with a check against an optional application specific SQL RC to Exception type mapping. We could supply a driver mapping utility to generate this mapping file for the most common errors. Just remember as I said at the start, this is from a few years back. The state of things may have changed. (but I know a lot of folks still using old drivers too...) Greg -Original Message- From: Christopher Thill [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 6:47 AM To: Apache Torque Users List Subject: Database independent error trapping. I am wondering if there is a way to do database independent error trapping. For example on a table/object that has a unique key I just invoke the .save() method and and trap any exception. I look at the exception to see if it was a duplicate value in the unique column that caused the error and then explain this to the user in a friendly message. My problem is that I want the system to portable to different database so I do not want to do something like: eSql = (SQLException) t; if ( !eSql.getSQLState().equals(23505) ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
