Re: [Gusdev-gusdev] SRes.ReviewStatus

[Jonathan C. <cra...@pc...>]

Arnaud-

> * What about an extra "automatically created" entry, along the "manually 
> created" one ?

We've decided to drop the "manually created" term, and while it would be
useful to know which entries were created automatically vs. manually,
this information can be tracked using a combination of the Evidence and/or
AlgorithmInvocation tables.  If you think it's crucial to record how an
entry was *originally* created, then we should consider adding an extra
column in the relevant tables to record this (and also to enable fast
queries to retrieve entries based on their origin.)

> * Curators here has raised another point : they want to be able to track 
> when was the last time the feature has been reviewed. By reviewed I mean 
> checked even if the review status is already set on "reviewed, correct". 
> Is there any way of storing a "last_checked_date" ?
> I'm thinking of curated similarity evidences. Regularly new searches 
> would be done and a curator would want to check that any new hit would 
> confirm or cancel a prediction.

I think that we're currently working under the assumption that we'll use the
modification_date for this (which may or may not meet your needs).  When an
annotator first reviews an unreviewed entry, its status is set to either
"manually reviewed, correct" or "manually reviewed, incorrect"  and its
modification_date is updated (and the old row versioned.)  The modification_date
now records the date of last review.  Now, when something happens that might
change the status of the entry (e.g., new searches are performed), its status
gets changed to "updated" and its modification_date is updated.  At this point
the only way to tell the date of last manual review is to look in the version
table.  (Although one does know that the last manual review must have been
before the stated modification_date.)  When the entry comes up for review
again (since it's now marked "updated"), its status is changed once more, and
it's modification_date will once again reflect the time of the most recent
manual review.

So the reason (in our current system) that we don't independently store the
last_checked_date is because we don't care when the entry was last checked
in absolute terms; we only care whether anything has changed since then.  One
problem with this (versus just storing a last_checked_date) is that it means
that any program that makes changes (e.g., the one that runs the similarity
searches) must determine what entries in the database *may* have been affected,
and update their review_status.

I think I agree that last_manual_review_date would be a useful thing to have,
but I think that its addition will have to be deferred until after I've
finished working on the migration, because it will affect several tables.
I'll put it on my list of things to deal with after the migration is done.

Jonathan