Dawn of Light

As I'm becoming more and more lazy (Well, not really the reason) lately and actually feel like logging in to do some database changes. I thought of a command which COULD actually be quite useful.

Code: Select all

Command: /sql
Usage example: /sql "UPDATE `Spell` SET `Field` = `Value`" (with the quotations around it)
PrivLevel: None. - ArrayList in the file so only certain accounts can do it, or have it work when a new priv system gets added in

Just to make stuff like setting spells easier really, so if you see a bug; you can fix in game... Most probably reasons why this is bad. But, I can see it a a good thing if done properly.[/i]

You'd have to be so sure of what your entering though.

You'd have to be so sure of what your entering though.

Yeah, that's why I can see people screwing up with it. Would be a useful command, but it's not necessary. (I mean, I'd use it if I found a wrong value in game, or fix it through the DB if I didn't know the field name) - Suppose it's just to make it easier than code.

It's a catch 22 sort of thing.

That would pretty much be passing the given string from the user to SQL function.

I can write this for you if you want, just put it as an admin level script and if people fail, then it's their own fault.

Might be a good idea to log all changes, maybe via a trigger or just plain SQL and store the old values somewhere so things can be rolled back if needed.

In my opinion, for this to really be useful, you would need a way to re-read whatever gets changed so it can be tested, otherwise you might as well run DAOC in a window and do the changes in another tool.

Logging changes would only help for things that COULD be rolled back. If you're fail enough to delete a database or something like that, there's issues.

As for reading back changes, I imagine that would just be done by issuing a SELECT statement.

That's a good point.

/sqlupdate and /sqlinsert might be a better idea than /sql

As far as logs, I wasn't clear. I mean something that will take the existing data and save it to another backup table. It's probably overkill, but always helpful.

So lets say an /sqlupdate is issued on table fred. First command would be insert into backup_fred select * from fred where ...

and then run the update on the primary table.

Like I said, probably overkill, but my job is to manage a 70G database that contains medical research data, so I'm pretty appropriately paranoid. Whenever I implement a feature that can remove data I also implement a backup table so we can recover from mistakes. It's easier that going to backups and provides that extra level of insurance.

I agree with you tolakram, which is why I'm so hesitant for something as powerful as this to be written.

Don't write it, even I'm cautious about it and I'm the one who'd use it the most.

I'd rather edit the database directly.