Isn't it more flexible that retrieveByPK *DOESN'T* return an exception? This allows you to throw your own exception if you want or deal with it in whatever way you see fit.
I believe there is an optimistic locking plugin... but remember HTTP is stateless :) -----Original Message----- From: symfony-users@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of pihentagy Sent: 06 February 2008 18:03 To: symfony users Subject: [symfony-users] (SQL) exception handling + locking Hi all! I'm reading the tutorials and I cannot find the section, when it is about exceptions (maybe I am overlooked it?) How symfony (and propel) handles exceptions in the SQL statements? What if there is an update, and the object in question is deleted in the meantime? Contrary, I am suprised, that retrieveByPK simply returns null, when the object with the PK does not exist! This way, I need to check the return value over and over against null. My opinion, that it would be safer to throw a (DataNotFound) exception in this case. What are the pros and cons? And what about consistency? Say request A loads an object, then request B loads the same object. Then request B changes the object, and finally request A want to save... Will it simply overwrite it? Is there an optimistic locking implemented? thanks Gergo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
