My eyes are getting tired and I'm not positive I'm reading that right. Are you suggesting that there are two issues going on? One of recursion and one of inefficiency? Or are you suggesting that even if the recursion is handled, the logic bringing you to the end result is still wrong?
If it's two separate issues, can we address the critical of recursion now and save the minor issue of efficiency for later? If the end result is inaccurate, I think I'm in your boat with the limited time. --- Scott Gray <[EMAIL PROTECTED]> wrote: > But that wouldn't that only work if the promo line > is to be reapplied? > If the promo no longer applies to the order > cancelOrderItem and > everything that goes with it needs to be used. I > can't see why the cart > is reloaded when you already have a cart in hand, > why not compare the > updated cart to the order and update items as > necessary rather than > rebuilding the adjustments from scratch? > > Chris Howe wrote: > > Ahh...I see now. recreateOrderAdjustments is > doing a > > sort of fake cancellation but using the big boy > > services to accomplish it. > > > > Perhaps it would be better to have the > simple-method > > update the OrderItem and create the > OrderItemStatus on > > it's own in that iteration section and not bother > with > > the service calls (with a comment as to why it's > being > > done this way)? > > > > Sound good? > > > > --- Scott Gray <[EMAIL PROTECTED]> wrote: > > > > > >> I did try option 3 a while back but there are > still > >> other problems with > >> the code, for example I think an order > notification > >> is triggered as a > >> seca on cancelOrderItem and also on > >> changeOrderItemStatus which results > >> in a ton of emails being generated. > >> > >>> There ;-) that's a loop. There should be two > ways > >>> > >> to > >> > >>> at least put a bandaid on it (and it may > actually > >>> > >> fix > >> > >>> it entirely). > >>> > >>> You can either check that the order item isn't > >>> currently canceled or you can call the java > method > >>> directly so that the SECA won't trigger. > >>> > >>> both solutions are attached. > >>> > >>> A third way is to make a second cancel order > item > >>> > >> that > >> > >>> does the exact same thing but by a different > name. > >>> > >> I > >> > >>> would think this redundancy is less desirable > than > >>> > >> the > >> > >>> other two. > >>> > >>> > >> > > > > > > > >
