Re: [ZODB-Dev] Reloading product in 2.8
Tim Peters wrote: [Jim Fulton] I agree. The right way to refresh is to detect code changes (ideally using Linux's brand new inotify mechanism, or something similar when inotify is not available), display a please wait message to the user, and restart the process. If you're changing more than one file, how could that know when the source code is in a globally consistent state again? (BTW, there are efficient ways to get notifications about modified files even on Win95, so that part isn't a hangup.) That problem turns out to be easy for Zope. The trick is to check for source code changes at the beginning of web requests, but no more often than once every two seconds or so. Developers hack for a while, producing a set of hopefully consistent changes, then test the new code just by making a browser request. Zope's auto-refresh feature works this way, and I think that part turned out quite successful. (I just realized there's an important use case: if the developer introduces an error that prevents the process from restarting, Zope needs to somehow bring the error to the developer's attention. The developer won't necessarily be staring at a terminal.) Shane ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Savepoints are invalidated once they are used
Tim Peters wrote at 2005-7-14 19:20 -0400: ... [Dieter] If we do, we can (usually) create a one with the state after the restore. [Tim] Sorry, I couldn't follow that sentence. After I have restored to a savepoint s, then the current state is the one saved in s, thus the sequence: s.restore() # and eliminate from stack s = transaction.savepoint() essentially recreates s and the situation I would get would restore not eliminate s from the stack -- modulo the fact, that s now contains a new savepoint object (and other bindings to the old object no longer work as expected). An s.push() would eliminate this drawback (at the expense of an additional method). -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Savepoints are invalidated once they are used
[Dieter] If we do, we can (usually) create a one with the state after the restore. [Tim] Sorry, I couldn't follow that sentence. [Dieter] After I have restored to a savepoint s, then the current state is the one saved in s, thus the sequence: s.restore() # and eliminate from stack s = transaction.savepoint() essentially recreates s and the situation I would get would restore not eliminate s from the stack -- modulo the fact, that s now contains a new savepoint object (and other bindings to the old object no longer work as expected). An s.push() would eliminate this drawback (at the expense of an additional method). Got it -- thanks. Part of the hangup was simply that what you call restore there is actually spelled rollback, and for some reason I didn't grasp that you were talking about the same thing (unsure why -- seems obvious enough today!). Anyway, for reasons explained before, making a savepoint would still need to copy the index, so I don't see that this would save anything worth saving. It might allow skipping an index copy when a _rollback_ is done (at the cost of clumsier coding for the user), but I don't care much about that expense. I do care about the expense of copying the index when a savepoint is made, but all schemes so far have that expense, regardless of whether they allow multiple rollbacks to a given savepoint (Jeremy misremembered when he wrote that the old scheme made a copy (solely) to support multiple rollbacks; it's also needed just to support nesting, which is the primary feature of savepoints). ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
