Thought it would be a good thing to post the IRC follow up: (16.15.20) hsarvell: What exactly happens when dbgc is run, what garbage is cleaned? (16.16.10) hsarvell: Is there garbage on disc? (16.21.40) Regenaxer: Well, all objects which are not references by any other object can safely be removed. (16.22.05) Regenaxer: s/references/referred/ (16.22.29) Regenaxer: If you press the "Delete" button on the GUI, the object is sent the lose!> message. (16.22.42) Regenaxer: This causes the object to be unlinked from all +Ref, +Key etc. trees. (16.23.03) Regenaxer: If it is then still referred by other objects (Joints, Links etc.), it will stay in the DB forever. (16.23.15) Regenaxer: Otherwise, 'dbgc' will call 'zap' on it. (16.36.57) hsarvell: I see so if I call lose!> on an object, it's still there there but unlinked, until I run dbgc? (17.08.14) Regenaxer: Yep. If you look at that object, you'll see that it has the 'T' property set. This is an indicator that it is 'lost'. (17.08.55) Regenaxer: The rule is that the "losing" procedure cuts all links *to* that object. Links *from* that object remain. (17.09.18) Regenaxer: So if you have, say, articles and orders. Order refer to articles by +Link. (17.09.43) Regenaxer: When an article is deleted, all old orders still point to their (out of date) articles. (17.10.40) Regenaxer: The trees with article-names, article-numbers etc. don't point to that article any more. It will not be found via normal search. Only when you open an old order and click on that article, you can get at it. (17.10.55) Regenaxer: This all proved very useful and makes sense in most contexts. (17.11.08) Regenaxer: If not, you can override the 'lose>' method for that entitity class. (17.11.42) Regenaxer: For example, in "app/er.l" there is a 'lose>' method for '+Ord'. (17.12.04) Regenaxer: This is there because we want all positions in that object to be recursively deleted, too.
On Tue, Jul 21, 2009 at 2:33 PM, Alexander Burger<a...@software-lab.de> wrot= e: > On Tue, Jul 21, 2009 at 10:07:38AM +0200, Henrik Sarvell wrote: >> That's it, dbgc and cron jobs, that rings a bell. Can you post an >> example usage of dbgc? > > Sure. > > Usually I have a crontab entry for that application's user. It calls a > nightly backup routine, e.g. at 1:12 o'clock: > > =A0 12 1 * * * ./p lib/http.l -'client "localhost" 12300 (pack "app/back.= l?*PW=3D" (pw))' -bye > > 12300 is the GUI port where that application is listening. So this line > will connect to the server and invoke "app/back.l", passing the password > in a local file ".pw". The reason for this password magic is that no > non-local process can start the backup. > > The first statement in "app/back.l" is > > =A0 (unless (=3D *PW (pw)) > =A0 =A0 =A0(quit "back.l" *PW) ) > > It quits immediately if the password does not match. Then it loads the > toolbox > > =A0 (load "lib/too.l") > > Logging is done to standard error (which is redirected to a log file): > > =A0 (out 2 > =A0 =A0 =A0# Timestamp > =A0 =A0 =A0(prinl "+ Backup " (stamp)) > > =A0 =A0 =A0# Terminate all > =A0 =A0 =A0(tell 'bye 2) > > This causes all sibling processes to be stopped, in case some users are > still working ;-) > > Then the database is exclusively locked: > > =A0 =A0 =A0(when (lock) > =A0 =A0 =A0 =A0 (quit "Can't lock DB" @) ) > > and a low-level check is done: > > =A0 =A0 =A0# Check integrity > =A0 =A0 =A0(for (F . @) *Dbs > =A0 =A0 =A0 =A0 (when (dbck F) > =A0 =A0 =A0 =A0 =A0 =A0(quit "DB Check" (cons F @)) ) ) > > The database is saved in tar file(s): > > =A0 =A0 =A0# Backup > =A0 =A0 =A0(call "sh" "-c" "tar cfz app$(date +%a).tgz db/app/") > =A0 =A0 =A0.... > > Now the garbage collector is called > > =A0 =A0 =A0# Garbage collection > =A0 =A0 =A0(when (dbgc) > =A0 =A0 =A0 =A0 (println 'dbgc @) ) > > After that, usually some other maintenance tasks are performed, like > updating data, sending mails to users about daily tasks etc., and > "app/back.l" terminates (because of the -bye one the command line). > > =A0 =A0 =A0# Exit > =A0 =A0 =A0(prinl "- Backup " (stamp)) ) > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe > -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
