Modify database structure to allow reviews with minimal information

[gunr2171]

Before we can have the User Watcher push deleted audits to the database, we need to set up the database to allow that information.

Depending on the information we are storing, I'll either make a new table for it or lessen the restrictions on the existing table.

However, the first thing we need is: @ArcticEcho, how much information do we have about deleted audits? Id numbers, dates, etc?

[ArcticEcho]

Well... we only have the number of deleted audits for a given review session (day). That said, the number is actually calculated by subtracting the number of logged reviews from the actual number reviews the user has completed; hacky, I know.

[gunr2171]

So when you poll the /review page to get the current number of reviews for a person, and you see that the number is 40, what happens? Do you search the user profile again for any new reviews, parse those first, then notify the rest of the system to announce the results?

If so, when that happens we can just write to the database that this person has 3 "missing reviews". The database table would be 3 columns:

• The date (UTC)
• The user's profile id
• The number of missing reviews

If a record is missing, assume it means the same as 0.

[ArcticEcho]

So when you poll the /review page to get the current number of reviews for a person, and you see that the number is 40, what happens?

Nothing. They've reached the limit so we assume they had no deleted audits.

Do you search the user profile again for any new reviews, parse those first, then notify the rest of the system to announce the results?

Nope, SOCVR.Net doesn't do any of this deleted audit processing and thus has no related events. UserTracking also doesn't do anything. We calculate the deleted audit count on the fly (whenever a stats command is called).

So... there isn't actually a nice way of logging this in an event-based way.

[gunr2171]

I'm looking at the UserTracking class, line 187.

private void HandleReviewingCompleted(User user, HashSet<ReviewItem> reviews)
{
    var revCount = user.CompletedReviewsCount;
    var userInRoom = room.CurrentUsers.Any(x => x.ID == user.ID);
    var chatUser = room.GetUser(user.ID);
    var msg = new MessageBuilder();

    if (userInRoom)
    {
        msg.AppendPing(chatUser);
    }

    var posts = reviews.Count > 1 ? $"{revCount} posts today" : "a post today";
    msg.AppendText($"{(userInRoom ? "You've" : chatUser.Name)} reviewed {posts}");

    var audits = reviews.Count(x => x.AuditPassed != null) + (revCount - reviews.Count);
    if (audits > 0)
    {
        msg.AppendText($" (of which {audits} {(audits > 1 ? "were audits" : "was an audit")})");
    }

This method is hooked up by

WatchedUsers[id].EventManager.ConnectListener(EventType.ReviewingCompleted,
    new Action<HashSet<ReviewItem>>(revs => HandleReviewingCompleted(WatchedUsers[id], revs)));

The way I understand this, the order of events are:

1. The library sees that you hit the max review items (40), and an event is fired
2. You start that method. revCount should be 40, and reviews is a list of all the reviews the Tracker has on file, including parsed audits.
3. audits = (count of parsed audits) + (the number of missing entries). You know how many reviews Stack Overflow says the person has done (by going to the /review page), and you have a list of parsed reviews. We just assume that anything missing from that list when you run the code is a deleted audit.
4. Once you have all the numbers, you print out in a chat room message. Nothing else gets called or run.

Does that sound correct?

[ArcticEcho]

Yep.

[gunr2171]

Ok, so how about this:

We keep the method (as in, we still call that method when you hit max items). However, instead of printing to chat, we do the following:

1. Do the audit computations as normal
2. Write that information to the database for the current person / day
3. Run the My Stats command as the current person

That way, the User Tracker doesn't need to print stuff to the chat room (its job is to track stuff, not presentation), and the database is the Single Source of Truth.

This would take some restructuring so that we can nicely call a chatbot method (or at least tell the command engine to run a wanted command).