Indicate on index page pending deletes as well as adds

Peter says it is also possible to say what is the expected lag. That would be highly useful for the user to know.

Would be overcomplicating matters to track when the last update happened so we could actually say when it is supposed to be committed?

I suppose so :)

Anyway, what is there is a huge step up. Works for me.

Looks like you have all the information here, but nothing it all blends together. I think users will care about whether search works, and if it doesn't work, how long will it take before its starts working again. IMHO, why its not working is secondary, as are number of terms/fields/documents in index.

Another way to address this is to hijack the deletion confirmation and append the string with "Search will be re-indexed in approximately 240 seconds." Or something like that?

Meaning when something is deleted, there's a confirmation. "X we deleted successfully" (or something to that effect). Change it to, "X was deleted successfully. The search index will reflect the deletion in approximately 240 seconds"

Hopefully this visual will clarify.

@Noys: Since we have muliple slaves, it will be pretty difficult to tell them when all of the slaves are up2 date. This is a much larger story.

I've attached a new patch containing Peter's changes, plus the last two notifications you wanted with a slight modification.

Here is a screenshot with what will be shown when someone deletes / unpublishes a node:
http://img.skitch.com/20090327-8wf82ksjctymcb2s1thpq8xjqt.jpg

Assuming we have 2 days, and the current functionality how could we improve this?

Here is a screenshot of Peter's patch in action:
http://img.skitch.com/20090327-rjnbuus5gr7tkwffu5w3p835m2.jpg

The reports page is just like the old index-settings page minus the form at the bottom.

----------------------

@pwolanin: the patch looks okay to me.

Re: http://img.skitch.com/20090327-8wf82ksjctymcb2s1thpq8xjqt.jpg. The Apache Solr message make sense, but can the message in sentence form vs bullet form? Assuming it's a bug to say the blog was deleted, then followed up with "the item was deleted"

Re: http://img.skitch.com/20090327-rjnbuus5gr7tkwffu5w3p835m2.jpg: Of the changes I see, I don't think they're significant enough. Looks like two items were replaced with one link.

@Noyz: Sentence vs. bullet - No. One message is generated by node module, one by us. Can't really change that AFAIK.

re: not significant enough

Needs more info here. Given the constraints I mentioned (we can't get authoritative info on when all slave servers are caught up in any easy way), what should we do?

@pwolanin: I agree about the deletion messages, but I'm trying to follow Jeff's screenshots. I'm not totally adverse to it, although it adds to the problem of people ignoring messages. Anyway, it might help.

-J

I believe Search starts producing accurate results as soon as one slave is updated - true? Can you benchmark off of one slave instead of all slaves?

Sorry, Peter, I'm not subscribed to this issue, so I don't know when you reply.

I think you're over engineeringthe solution. Users will not hold us accountable if the time isn't completely accurate. All they only need to know is if it's not working, and if its not, how long will it be until it starts working. To address the later, I believe the following options will work (so long as the data is not surrounded by a bunch of other data):

- ...Apache Solr will be re-indexed in approximately 5 minutes. //it may be wrong, it may be longer, but it at least tells them why it's not working. // you could even say 15 minutes, and if it comes in early they'll be happy.

- ...Apache Solr will be re-indexed in approximately [get the approximate time from Solr] ///more precise yes, but I thought you couldn't do this because you had no idea how long it would take to persist across slaves, and distribution is unevenly spread.