Thanks Brian - I realise that, but we have to modify the contents of the iterator before validation and we can not do this without these modifications being performed on the database. We really want to be able to modify the iterator, validate and then only persist the changes *if* validation passes.
On 11/9/06, Brian Kotek <[EMAIL PROTECTED]> wrote:
The iterator has it's own validate method which you can call directly if you need to. You don't have to rely on the parent record's validate() method. On 11/8/06, Mark Stanton <[EMAIL PROTECTED]> wrote: > Guys can I get some more responses on this please. It's becoming > increasingly urgent and is a major problem for us. > > > On 11/8/06, Mark Stanton <[EMAIL PROTECTED] > wrote: > > Thanks for the response Qasim - however we are in a position where we > > need to validate the new state of the iterator before we can save. > > > > On 11/7/06, Qasim Rasheed < [EMAIL PROTECTED]> wrote: > > > Mark, > > > > > > I recently encountered a similar situation and following was my take on this > > > (all psuedo-code). One thing to note is that my iterator didn't needed any > > > validation. > > > > > > 1. Load Record > > > 2. Load Iterator > > > 3. Start Transaction action="begin" > > > 4. try > > > 5. validate Record object > > > 6. if no error(s) then all following step else just show user the original > > > form > > > 7. loop through iterator and delete those one by one (I wish deleteAll has a > > > useTransaction argument) > > > 8. Add the new/current relationships into the iterator > > > 9 Save Iterator > > > 10 transaction action="commit" > > > 10 catch - transaction action="rollback" > > > 11 end try > > > > > > HTH > > > > > > > > > On 11/5/06, Mark Stanton < [EMAIL PROTECTED]> wrote: > > > > Hi All > > > > > > > > We have run into a bit of a brick wall with Iterators and was hoping > > > > someone could point us in the right direction. > > > > > > > > To illustrator the problem I'll use an example: > > > > > > > > We have a UserGuideRecord object which has a title, a document and a > > > > many to many relationship to RoleRecord objects.The semantics of this > > > > relationship are - which user roles is this user guide relevant to. > > > > > > > > If I have an existing user guide and I want to edit it and modify the > > > > roles I currently go through the following process: > > > > > > > > - Load the existing UserGuideRecord > > > > - Get the UserGuide_RoleIterator > > > > - Delete all the current relationships from the iterator > > > > - Add the new/current relationships into the iterator > > > > - Validate the record > > > > - If no errors were found, save the record, otherwise return the user > > > > to the form > > > > > > > > The problem is that if validation fails, all the existing > > > > relationships have been deleted and are now lost. > > > > > > > > We had originally assumed that deleteAll - marked items for deletion > > > > and that until save() was called, no write operations were performed > > > > on the database. However this is not the case - deleteAll() physically > > > > deletes everything in the iterator from the pivot table. > > > > > > > > Does anyone have any suggestions about how to work around this? > > > > > > > > > > > > Cheers > > > > > > > > Mark > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Mark Stanton > > > > Gruden Pty Ltd > > > > http://www.gruden.com > > > > > > > > > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > -- -- > > > > Reactor for ColdFusion Mailing List > > > > [email protected] > > > > Archives at: > > > http://www.mail-archive.com/reactor%40doughughes.net/ > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > -- -- > > > > > > > > > > > > > > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > -- -- > > > Reactor for ColdFusion Mailing List > > > [email protected] > > > Archives at: > > > http://www.mail-archive.com/reactor%40doughughes.net/ > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > -- -- > > > > > > -- > > Mark Stanton > > Gruden Pty Ltd > > http://www.gruden.com > > > > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > Reactor for ColdFusion Mailing List > > [email protected] > > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > > > > > -- > Mark Stanton > Gruden Pty Ltd > http://www.gruden.com > > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > Reactor for ColdFusion Mailing List > [email protected] > Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- Mark Stanton Gruden Pty Ltd http://www.gruden.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
