MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Database editors

>Why is this a bad thing?  If I got $0.10 for every time I heard about 
>another lone wizard on another MOO who forgot his or her password and 
>need to put in a new one, I'd be a rich man.  Okay, maybe not rich... but 
>I'd have enough to buy a Whopper or something.

1.  You shouldn't be forgetting your password (I will contend that most
    people have a problem with passwords tho).
2.  It's still easier (and faster) to change verb code than to set a property,
    and a db editor would have to read in the editor db in order to operate 
    at all on it (and have a nice user interface, which I assume everyone
    would want).

>I just added that in because yes, I did hear one or two instances where 
>#2's player flag was removed.  Sure, it's a stupid thing.  Just that it 
>has happened, so an editor, maybe, ought to handle it.  That's the only 
>use really for a database editor: doing things that can't be done with 
>LambdaMOO or fixing a broken database that can't be loaded or brought 
>under control.

Databases can only be 'broken' by human error (databases truncated or
 corrupted by server are unusable/unstable anyway), hence:

I still hold that if a db editor did exist, then it should only be able to do
two things:

1.  set an object's wizard bit
2.  program #0:server_started

Let's take an example:
#2's (or #3, if miminal db -- I'll just use $archwizard) player flag gets
 take away.
$archwizard's programmer flag gets taken away
$archwizard can't remember 'is password.

Fixable with:

find #0:server_started in the db file (first line should be a comment
 containing "SERVER STARTED"; to make it easier to find)
add these lines:

#0:5
"SERVER STARTED";
set_player_flag(#2, 1);
#2.programmer = 1;
#2.password = crypt("password");
or
#2.password = 0;
... rest of code

at the top of the code. restart. all fixed.  Just remember to remove those
 lines from :server_started.

>I agree, it 
>would be better if someone created a porting object to handle porting 
>between MOOs... maybe one logs into the second via $network and sends the 
>object?

I'm working on something similar to this, and there is an FO on lambda that
 does it.

>And, every single time, it was on a MOO that backs up only once every day 
>because of limited RAM or a slow CPU, or maybe even less often, and it 
>always occours right after the tired wizard has just finished an 
>extremely huge and groundbreaking day long project.  I think that having 
>a (very simple) database editor would be an advantage, just to handle 
>common causes of corruption.  Maybe search through the database and look 
>for corrupt things and report where they're at so if you're a decent db 
>editor, you can fix it?

Anything that can't be fixed using the two cases listed above can't be fixed.

You shouldn't be doing serious development work on a MOO that only checkpoints
 once a day, unless you *like* to play with fire.
  ______                              __
    /   /  Andy Bakun     _/_      / /  `  /)  /)       _/_
 --/   /_  , , , __.  __  /  _  __/ /--   //  //  __,_  /  _
(_/   / /_(_(_/_(_/|_/ (_<__</_(_/ (___, //__//__(_) (_<__/_)_
  How much head could a bonehead bone   />  />
    if a bonehead could bone head?     //  //
  http://tecfa.unige.ch:4243/~tef/    </  </
Follow-Ups:
Home | Subject Index | Thread Index