Not sure how this happened but about a week ago all existing users lost their subscriptions (groups, nodes, etc.) on one of our production sites. Since then there have been a lot of new users and content posted. New users are autosubscribing correctly.
When I look at the notifications, notifications fields, and notifications events tables in the DB, it looks like they only contain the new subscriptions for new users. I am assuming that the tables got truncated accidentally.
So, I would like to know how to address this. I see that I have these options:
#1. Use a DB backup to append to the existing notification tables
Find a known good backup with the notification tables data and append/insert all of these records into the existing notifications tables. This is preferable since it should also pick up subscription/notification opt outs and changes they made.
#2. Edit each user's subscriptions by hand.
For each user, edit their subscriptions and subscribe them to each group, content, etc. Somehow also subscribe them to each of their posts. We have a few thousand users with N groups and X posts. This would be painful.
#3. Write some PHP to pragmatically add subscriptions/notifications for each user
Basically, create the notifications, notifications_fields, notifications_events tables records for users that do not already have records in the table - including each group for which they are a member. Maybe there are some APIs/functions in notifications that I can use to help with this. This approach would force every user to be resubscribed to all their group content/postings. This seems daunting, too.
Are there any other alternatives?
I would prefer to use Option #1, but will it work: just insert the old records into the existing tables? Could this result in some orphaned records that will never get cleaned up?
Thanks for the help!
Comments
Comment #1
gregstout commentedIn case anyone has this same issue. I was able to use approach #1. I just used the backup data to create some SQL Insert statements and then I ran a bulk SQL insert on the tables above.
This way I was able to keep the new subscriptions and add the old subscriptions. I don't seem to have any problems - and it has been up and running for a couple of weeks.
Comment #2
gregstout commentedComment #3
slimabraham commentedHi - just wondering if you ever had any recurrence of this issue? We encountered a similar problem a couple of weeks ago where all subscriptions were dropped from the db. It has happened again since a couple of times. Did you ever find out what caused the table to be truncated?
Thanks.
Comment #4
gregstout commentedNo, never found out the problem. I have a feeling that it was truncated during testing. We have since then taken measures to prevent that from happening. It has not occurred since then.
Comment #5
farazmulla commentedHi Greg,
Can you let us know what steps you have taken during testing that have worked. Did you upgrade the drupal version by any chance as well or are you running the same version as the one you had when you faced the issues
Thanks,
Faraz
Comment #6
farazmulla commentedHi ,
How did you fix this. We have had the same issues since a week.
Thanks,
Faraz
Comment #7
farazmulla commentedComment #8
gregstout commentedsorry, didn't see this earlier.
We couldn't replicate it or find a reason for it.
I had upgraded to the latest modules for notifications and messaging (as they should be version synced).
It has not occurred again since that time.
We had some backups and used them to recreate the notifications. Then we just "reset" all users to have the same subscription/notification schedule of every three days. (By reset, I mean we used an SQL statement to change all user's intervals.)
Comment #9
gnindl commentedWe encounter a similar re-occurring issue.
Our subscription tables, i. e. notifications and notifications_fields, loose some entries from time to time. Basically all subscription preferences for a specific node type and/or taxonomy term are completely wiped out! We use version 4.0-beta7 and the API function notifications_delete_subscription().
It's very annoying as we have to re-insert missing data into our subscription tables.