Well, I'm !sure how usual this scenario would be: 1. In general those using solr with nutch don't store the content field to avoid storing the whole web/intranet in their index, twice (1 in the form of stored data, and one in the form of indexed data).
Now everytime they need to update a field unrelated to content (number of inbound links for an example) they would have to re-crawl the page again. This is at least !intuitive. On Wed, Jul 13, 2011 at 2:40 PM, Michael Kuhlmann <s...@kuli.org> wrote: > Am 13.07.2011 14:05, schrieb Gabriele Kahlout: > > this is what i was expecting. Otherwise updating a field of a document > that > > has an unstored but indexed field is impossible (without losing the > unstored > > but indexed field. I call this updating a field of a document AND > > deleting/updating all its unstored but indexed fields). > > Not necessarily. The usual use case is that you have some kind of > existing data source from where you fill your Solr index. When you want > to update field of a document, then you simply re-index from that > source. There's no need to fetch data from Solr before. > > Otherwise, if you really don't have such an existing data source because > a horde of typewriting monkeys filled your Solr index, then you should > better declare all your fields as stored. Otherwise you'll never have a > chance to get that data back. > > Greeting, > Kuli > -- Regards, K. Gabriele --- unchanged since 20/9/10 --- P.S. If the subject contains "[LON]" or the addressee acknowledges the receipt within 48 hours then I don't resend the email. subject(this) ∈ L(LON*) ∨ ∃x. (x ∈ MyInbox ∧ Acknowledges(x, this) ∧ time(x) < Now + 48h) ⇒ ¬resend(I, this). If an email is sent by a sender that is not a trusted contact or the email does not contain a valid code then the email is not received. A valid code starts with a hyphen and ends with "X". ∀x. x ∈ MyInbox ⇒ from(x) ∈ MySafeSenderList ∨ (∃y. y ∈ subject(x) ∧ y ∈ L(-[a-z]+[0-9]X)).
