Reformatted excerpts from Daniel Wagner's message of 2008-12-07:
> entries in the dump file 26462
What is this number from? Is it a wc -l on the dumpfile, or sup-sync's
"Restored state on X messages" message? If the latter, what is wc -l?
(And if the former, what's the other number?)
> entries scanned 24779
> entries added 24373
> warnings 27
> fakes 75
Warnings and fakes we can ignore. (They still count as being added.)
Did sup-sync report a number of updates?
It should be the case that num adds + num updates = num scanned,
and num adds = index size (when starting from an empty index).
> The Numbers According To sup
> old machine new machine
> messages in the index 26459 24416
> messages with +inbox 50 45
> messages with +Starred 67 57
>
> So, I'm not sure I understand how to reconcile these numbers. Things
> are mismatched in odd ways; for example, how could there be more
> entries in the dump than there are messages in the index?
Yes, that is weird. 26462 vs 26459 is what concerns me. How did three
new messages appear at dump time?
> Or how come "entries added" + "warnings" != "messages in the index"?
Messages with warnings or that needed fake headers should still be
added, so the question is really 24416 vs 24373. That's 43 new messages
that appeared in the index.
> That's okay, though. There are people for whom impermanence is a way
> of life.
Uh oh.
> There are a few categories of messages for which I really, really
> want the impermanence to start later, though -- specifically +inbox and
> +Starred messages. Since there's only 15 of these lost, is there some
> way I can grab/index those manually?
The most direct way is to query the index through devel/console.sh. You
can find examples on the wiki or in the mailing list archives. Something
like
Index.ferret.search("label:inbox", :limit => :all).hits.map { |h|
Index.ferret[h.doc] }
will give you all the Ferret records with the index label, and you can
then query them for all the fields listed in index.rb. (They'll appear
as empty hashes, {}, when irb prints them out, but in reality they're
just lazily-filled.
That should give you the information you need to compare the two sets of
documents on both indexes, and figure out what the differences are.
--
William <[email protected]>
_______________________________________________
sup-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/sup-talk
