<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 26, 2016, at 10:31 AM, Richard Newman <<a href="mailto:rnewman@mozilla.com" class="">rnewman@mozilla.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">To speak to part of this:</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To head that off, I’d like to fix rollbacks in general. So here I am, asking for what other people want from it.<br class=""></blockquote><div class=""><br class=""></div><div class="">"Undo" is a really tricky problem if the data makes it to the database.</div><div class=""><br class=""></div><div class="">You can't roll back the transaction (it's committed).</div></div></div></div></div></blockquote><div><br class=""></div><div>There was code for cancelling/rolling-back. Remnants are still there. I just looked at the top level so far, so I don’t know exactly how it does it other than accumulating a buffer of changes.</div><div><br class=""></div><div>I can get tricksy, but don’t know if I can do that enough to solve the problems.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">You can't just write the old state directly to the DB — as soon as the change hits the database, Sync is going to upload those changes, altering metadata as it goes. (In general, you cannot write directly to Places at all.)</div><div class=""><br class=""></div><div class="">And writing a computed reverse-diff through the API is also hard to get right — by the time you try to change things back, Sync might have merged in new changes.</div></div></div></div></blockquote><div><br class=""></div><div>Oh! Didn’t think about sync and this problem. It’s a real problem, and I will have to think about it. I do want to have multiple readers/writers to the databases in the future, so it needs to get solved. The sync guys will care about it, so at least maybe I’m not alone.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">If data doesn't hit the database… well, that's another set of problems.</div></div></div></div></blockquote><div><br class=""></div>Yeah. I’ve been thinking about the problems involved in using in-memory databases for speed. I have no comfortable solutions yet (for persistence, etc).</div><div> <blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The editor window is too small and unresizable, the tag list changes width as you scroll it, etc. With my two extensions, tags are now (with ESR45) quite useful, and you can have minutes long sessions editing tags, making cancel a necessity. </blockquote><div class=""> </div><div class="">If you're making changes over the course of minutes, and those changes are applied to Places, then those changes have synced to other devices and might indeed change underneath you during editing.</div></div></div></div></blockquote><div><br class=""></div>Getting sync to work right seems to help me maintain consistency with multiple readers and writers. Rolling back would confuse sync though, I’ll need to study that one. But just undo brings up the rollback problem.</div><div><br class=""></div><div>Interesting!</div><div><br class=""></div><div><br class=""></div><div>Thanks for bringing up sync. It was the sort of thing I was fishing for!</div><div><br class=""></div><div>— Perry</div><div><br class=""></div></body></html>