that's what encouraged me to originally post (instead of heading to the pub to drown my sorrows and not coming back)...
- whether I could get away with a Memento-like pattern for this. I think the deciding factor will be the chance of how many people at any one time will be hitting the same record - data collision when doing writes via webservices is always going to be a hassle - but this would be even more painful. as for the "smallest possible" atomic piece of work that could be rolled back, the only thing smaller than individual entities are the individual properties it has. "Speaking from experience however, that can be a year(s)+ wait." honestly? it's been rumoured for the next version next year, but given how they've built this thing in the first place (and how we're pushing it's boundries), I reckon their statement (and/or it doing what we need) is pure vapourware and pigs might fly first. thanx again for your suggestions/shoulder to cry on. b > I've been in this, um, "position" before, and there's always a way. > > Some form of automation is usually preferable to none, so, well, what > about a little bit of double-duty? > > I'm not sure how the entities are set up, but perhaps with each job, > you create the corresponding anti-job. > > [1]["command"] = "create entity bob" > [1]["anti-command"] = "delete entity bob" > > [2]["command"] = "add alice as child of bob" > [2]["anti-command"] = "remove child alice from bob" > > And then just run through things in reverse when you hit an error? Or > perhaps you can store the state of each entity prior to updating > (automatically), and just run through the structure in reverse, > re-setting each entity to it's pristine state? > > A lot of it really depends on how the jobs are structured, and how you > can logically break them up into the smallest possible revert-able > unit. > > If you *do* automate it, chances are you'll be running a lot more > transactions than a normal client, so if there's audit logs and > whatnot, that humans have to go through... well, just take it into > consideration, I reckon. > > > So there's things like that, or, you can spend your time being > productive while you wait for the owner of the app to implement the > needed functionality. > > Speaking from experience however, that can be a year(s)+ wait. > Sometimes it makes sense to do what you can to speed up your own end > (and reduce entry errors and whatnot). Sometimes it doesn't. Most of > the ones I've chose to do have been worth it. "Worth it" == > if((development time - time it takes to do it manually X times) gt 0). > > There *is* only so much time in the world tho, even if you're saving time. > > Maybe just push the whole shibosh onto some poor lower-paid minion. > "Sorry, the work-studies are going to have to do that by hand until > the vendor implements solution X". > > Yeah... that works, too. > > -- > Men fear death as children fear to go in the dark; and as that natural > fear in children is increased by tales, so is the other. > Francis Bacon > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
