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
>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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -