Forum OpenACS Q&A: Nuking users

Collapse
1: Nuking users
Posted by Reuven Lerner on 09/03/02 01:28 PM
I'm working on an OpenACS site that will add users en masse.  (One of
the participating organizations sent me a data file with 12,000 users,
for example.)  I'm trying to test my custom registration system, but
have discovered (like some others on the bboard) that deleting a user
doesn't remove the entry from the "parties" table.  And because an
e-mail address has a UNIQUE constraint in Parties, this means that I
can't re-add the same user during a second (or third, or tenth)
iteration of my test.

If it were as simple as deleting entries from the Parties table, I
would do that.  But there are some other tables involved as well,
including acs_rels, and going through all of this manually is a real pain.

The reason for keeping people around in Parties is that we want to
keep all content on the site, including whatever content was created
by deleted users.  But in my case, I know that the users haven't
generated any content, and I want to remove any trace of them from the
system.

So, what realistic options do I have?  OpenACS 3 had a handy-dandy
"nuke" feature that I haven't seen in OpenACS 4.

Ideas, anyone?

Collapse
2: Response to Nuking users (response to 1)
Posted by Caroline Meeks on 09/03/02 03:08 PM
If the user has not contributed any content its not hard to nuke them.  Andrew wrote a page to do it for SloanSpace and I can email you that if you want.

The meat of it is one line of code:

db_exec_plsql nuke_user { begin acs.remove_user(:user_id); e
nd;

Collapse
3: Response to Nuking users (response to 1)
Posted by Reuven Lerner on 09/03/02 03:12 PM
Please!  I would be delighted to see it.

(And I'm sure that others would, too!)

It sounds like you wrote it for Oracle; I need it for PostgreSQL, but will gladly translate it and make it available.

Collapse
4: Response to Nuking users (response to 1)
Posted by Tom Jackson on 09/03/02 05:58 PM

For those who can't delete the party, you can optionally change the email to something guaranteed not to be an email. I used something like 'deleted' + party_id as replacement text.

Even if you find a convenient method to delete users who have not contributed content, you will probably find deleting 12,000 users to be inconveniently slow. You should finish your testing and reinstall the system. Deleting objects is not fast. Probably what we really need is a script that can temporarily drop constraints that slow down the process and clean out the old objects, then recreate the constraints.

Another thing we need is to someday move the email or login_id used for logins to something besides parties. Parties cannot login, and data from that table should not be used to log the user in.

It might actually be nice to abstract out the contact method for a user. Maybe a table like 'user_contacts' might contain a contact method, the address or user_id (like AIM handle or Jabber address, or Post URL), plus a preferred contact method.

Collapse
5: Response to Nuking users (response to 1)
Posted by Reuven Lerner on 09/03/02 07:36 PM
Tom,

Ya know, I had previously nixed the idea of changing the e-mail address to something else.  But your idea of "deleted" + party_id is an excellent one.

If I were only dealing with one set of 12,000 entries, then I would gladly get it right, then reinstall from scratch.  (I've seen how long it can take to delete that many rows, and here we're talking about a bunch of triggers firing as well.)  The problem is that I'm bringing together similar numbers of entries from a number of organizations that are joining together for this project.  So as soon as I check that the initial 12,000 entries are OK, I've got several more (albeit smaller) batches coming along afterwards.  Clearly,  this is one of those projects for which you want two databases, one for development and the other for production.

I got the "nuke" scripts from Caroline, and hope to give it a whirl later this evening...

Collapse
6: Response to Nuking users (response to 1)
Posted by Rafael Calvo on 09/08/02 01:42 AM
Mark  Aufflick in my group had fixed the problem. I will remind
him to post the patch.