At 02:34 PM 11/27/00 -0800, Ben Schochet wrote:
Seems that way Steve.
I have tried to do this in an external method with self.get_transaction.commit(1) before doing the changeProperties, but that didn't seem to work.
You want get_transaction().commit(1), if you're doing it from Python. DataSkins also have a commitSubtransaction() method that can be used to do this.
Is there another way to do this? the CHANGE trigger works fine on its own.
How are others creating new items with properties from an HTML FORM? Should I be doing this another way?
I can't wait to figure out ZPatterns, I think it is the best way to create Zope applications! It seems to allow you to have the best of Zope objects along with your data secure and accessible from a RDBMS. (At least that is the value I see, there are probably others...)
You can't have an ADDED and CHANGED both fire in the same subtransaction. ADDED, CHANGED, and DELETED are mutually exclusive. So your ADDED trigger has to perform the same operations to save data as your change trigger would. One easy way to do this is to do: WHEN OBJECT ADDED ...stuff to do for adding only WHEN OBJECT ADDED,CHANGED ...stuff to do when changing or adding Since the triggers are fired in order, and both triggers fire on add, that should be pretty easy to set up. Note that in this case, you won't need to commit a subtransaction. Subtransaction commits are really pretty rarely needed. About the only time you should *normally* need a subtransaction commit is that if you have triggers you want to take effect before you move on, like triggers that update an index you're about to search. The normal assumption in Zope however is that you generally keep your read and write transactions seperate; i.e. a POST usually results in a redirect to the updated object, or something of that sort.