Hi Otis,
Thanks for the response. I was actually talking about the initial
sync over from the master. what I'd like I guess is a "lock" command
which would start true, and when snapinstaller ran successfully for
the first time would become false. I can write the bash, but I'm not
sure how to ge
context is available for each entity but the implementation just
stores one value for last_index_time.
If it stored the last_index_time per top-level entity it could return
the correct value from context.
Anyway raise an issue and I can provide a patch soon
something like this also shall be suppo
> I have not worked with SSDs, though I've read all the good information that's
> trickling to us from Denmark. One thing that I've been wondering all along is
> - what about writes? That is, what about writes "wearing out" the SSD? How
> quickly does that happen and when it does happen, what ar
I have not worked with SSDs, though I've read all the good information that's
trickling to us from Denmark. One thing that I've been wondering all along is
- what about writes? That is, what about writes "wearing out" the SSD? How
quickly does that happen and when it does happen, what are the
Hi Kevin,
Find the component that's stripping your " and ' characters (WordDelimiterFF?)
and make sure those characters are indexed first. Then make sure the
query-time analyzer keeps those tokens, too. Finally, escape special
characters (e.g. " in your example) in the query before passing i
Hi Chris,
Yes, from what you described, Solr sounds like a good choice. It sounds like
for each type of entity (doc vs. product vs... ) you may want to have a
separate index/schema. The best place to start is the tutorial.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Even with your current setup (if it's done correctly) slavs should not be
returning 0 hits for a query that previously returned hits. That is, nothing
should be off-line. Index searcher warmup and swapping happens in the
background and while that's happening the old searcher should be serving
Would that context but available for *each* entity? @ present it
seems like there should be a last_index_time written for each top
level entity ... no?
Umm would it be possible to hack something like ${deltaimporter.[name
of entity].last_index_time} as is or are there too many moving parts
the if an entity is specified like entity=one&entity=two the command
will be run only for those entities. absence of the parameter entity
means all entities will be executed
the last_index_time is another piece which must be improved
It is hard to get usecases . If users can give me more usecase
Hi,
I'm running multiple instances (solr 1.2) on a single jetty server using JNDI.
When I launch a slave, it has to retrieve all of the indexes from the
master server using the snapuller / snapinstaller.
This works fine, however, I don't want to wait to activate the slave
(turn on jetty) while w
10 matches
Mail list logo
